[Rdiff-backup-bugs] [bug #27729] Permission denied when renaming rdiff-backup.tmp file

[Kurt]

Follow-up Comment #2, bug #27729 (project rdiff-backup):

So, I noticed something else: rdiff-backup.tmp.9770 in this case points to
/etc/ssl/private. This file is not readable by the backup user on my backup
machine. 

After encounting the same problem on another backup, I ran an strace on it
and noticed the following system calls leading up to the error:

22969
lstat("/backups/anotherhost/var/lib/postgresql/8.3/main/rdiff-backup.tmp.5785",
0x7ffff
fae9e70) = -1 ENOENT (No such file or directory)
22969 symlink("/etc/ssl/private/ssl-cert-snakeoil.key",
"/backups/anotherhost/var/lib/postgresql/8.3/main/rdiff-backup.tmp.5785") = 0
22969
lstat("/backups/anotherhost/var/lib/postgresql/8.3/main/rdiff-backup.tmp.5785",
{st_mode=S_IFLNK|0777, st_size=38, ...}) = 0
22969
readlink("/backups/anotherhost/var/lib/postgresql/8.3/main/rdiff-backup.tmp.5785",
"/etc/ssl/private/ssl-cert-snakeoil.key", 1023) = 38
22969
listxattr("/backups/anotherhost/var/lib/postgresql/8.3/main/rdiff-backup.tmp.5785",
(nil), 0) = -1 EACCES (Permission denied)
22969 write(3, "Warning: listattr('/storage/sysb"..., 136) = 136
22969 write(1, "Warning: listattr('/storage/sysb"..., 136) = 136
22969
listxattr("/backups/anotherhost/var/lib/postgresql/8.3/main/rdiff-backup.tmp.5785",
(nil), 0) = -1 EACCES (Permission denied)

After this, I see system calls that are presumably rdiff-backup exiting with
a stack trace:

22969 stat("/usr/lib/python2.4/site-packages/rdiff_backup/Main.py",
{st_mode=S_IFREG|0644, st
_size=36069, ...}) = 0
22969 open("/usr/lib/python2.4/site-packages/rdiff_backup/Main.py", O_RDONLY)
= 8
22969 fstat(8, {st_mode=S_IFREG|0644, st_size=36069, ...}) = 0
22969 fstat(8, {st_mode=S_IFREG|0644, st_size=36069, ...}) = 0
22969 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2aaaadea20
00
22969 read(8, "# Copyright 2002, 2003, 2004, 20"..., 8192) = 8192

...and so on.


So, what I think is happening is that rdiff-backup on the backup server
(*not* the backup target) is trying to get status on the target of the
symlink. On the backup server, rdiff-backup is being invoked by a
non-privileged user. Since the symlink target is not readable by the
non-privileged user on the backup server, the symlink status fails, and
rdiff-backup aborts. Thus, rdiff-backup needs to handle symlinks on the backup
server more intelligently.

Thus, the instructions to reproduce this problem must be amended: 

- set up an Ubuntu Hardy "server" with rdiff-backup, and install openssl on
it (this creates the only-readable-by-root /etc/ssl/private)
- set up an Ubuntu Hardy "client" with rdiff-backup, likewise installing
openssl on it
- run rdiff-backup from the server as a non-privileged user, for example user
"backup"

If my analysis above is correct, a backup using the above scenario should
fail.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?27729>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/