Hi, # id uid=0(root) gid=0(root) groups=0(root) # cd /tmp # mkdir a # : > a/1 # chmod 0 a # ls -ld a d--------- 2 root root 60 27. Jan 17:07 a # ls a 1 # rsync -a --rsync-path='strace -o /tmp/rsync.st rsync --fake-super' a joerg@localhost:/var/tmp rsync: failed to read xattr user.rsync.%stat for "/var/tmp/a": Permission denied (13) rsync: failed to read xattr user.rsync.%stat for "/var/tmp/a": Permission denied (13) rsync: failed to read xattr user.rsync.%stat for "/var/tmp/a": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1057) [sender=3.0.6] # ls -ld /var/tmp/a d--------- 2 joerg users 4,0K 27. Jan 17:07 /var/tmp/a From the strace: lstat64("a", 0xbfe8e68c) = -1 ENOENT (No such file or directory) mkdir("a", 0) = 0 lstat64("a", {st_mode=S_IFDIR, st_size=4096, ...}) = 0 lgetxattr("a", "user.rsync.%stat", 0xbfe8c318, 255) = -1 EACCES (Permission denied) … lstat64("a", {st_mode=S_IFDIR, st_size=4096, ...}) = 0 lgetxattr("a", "user.rsync.%stat", 0xbfe8c0d8, 255) = -1 EACCES (Permission denied) … chmod("a", 0700) = 0 lsetxattr("a", "user.rsync.%stat", "40000 0,0 0:0", 13, 0) = 0 I think the problem is, that rsync server creates the directory with the permission of the client which does not mean that they are usable when running with --fake-super. I found no way to make the server creates the directories and files with other permission, but keeping the right permissions in the extended attribute. When using --chmod=u+rX on the server side, this changes also the permission in the attribute. Bye, Jörg
Created attachment 5226 [details] Output of strace of rsync on the server side
Right. The same problem occurs with a single regular file. Rsync sets the correct permissions (granting the owner all permissions) in set_stat_xattr, but that is too late. It needs to enable read permission when initially creating a regular file or directory. Note that one --fake-super issue (directory permissions incorrectly being retouched) was fixed in 3.0.7, but this is a separate issue.
Created attachment 5897 [details] Fix-temp-file-perms-to-allow-reading-xattrs (In reply to comment #2) > Right. The same problem occurs with a single regular file. The regular file version of the problem can be fixed with the attached 'Fix-temp-file-perms-to-allow-reading-xattrs' patch. I'm not confident enough of how/when the directory permissions are updated to make a similar change to fix that side of things. For the record, the regular file version of the problem can be duplicated like so: rsyncd.conf: [test] path = /tmp fake super = yes use chroot = no read only = no $ touch /tmp/a $ chmod 0 /tmp/a $ sudo rsync -lt -av -e 'ssh' /tmp/a "localhost::test/b" sending incremental file list a rsync: failed to read xattr user.rsync.%stat for ".b.xhD81x" (in test): Permission denied (13) rsync: failed to read xattr user.rsync.%stat for ".b.xhD81x" (in test): Permission denied (13) sent 76 bytes received 27 bytes 13.73 bytes/sec total size is 0 speedup is 0.00 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1057) [sender=3.0.6] $ ls -l /tmp/a /tmp/b ---------- 1 chris chris 0 2010-08-12 14:47 /tmp/a -rw------- 1 nobody nogroup 0 2010-08-12 14:47 /tmp/b
Created attachment 5950 [details] Patch to fix fake-super permissions
(In reply to comment #2) > Rsync sets the correct permissions (granting the owner all permissions) in > set_stat_xattr, but that is too late. It needs to enable read permission when > initially creating a regular file or directory. The rsync manual says of fake-super, "any permission bits ... that would limit the owner's access" should be stored in the xattr rather than on the real file. So we need to make sure the owner has full permissions on created files (at least mode 600) and directories (at least mode 700). This also avoids the permissions error when trying to read the xattrs on a mode 000 file or directory just after we create it. The attached 0001-fake-super-give-owner-full-permissions-on-created-fi.patch contains testsuite/fake-super.test which demonstrates the problem for both files and directories, and a proposed fix for both. With the fix rsync passes all the tests.
I've adapted the patch for release in 3.0.8. There was already some --fake-super testing in xattrs.test, so I added a test that checks for files/dirs with mode 0. The suggested fake-super.test would only have worked when run as root, which isn't always the case. Thanks!