Bug 7070 - Permission denied message with --fake-super and permissionless directory
Summary: Permission denied message with --fake-super and permissionless directory
Status: RESOLVED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.6
Hardware: x86 Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-27 10:27 UTC by Jörg Sommer (mail address dead)
Modified: 2011-01-01 19:05 UTC (History)
0 users

See Also:


Attachments
Output of strace of rsync on the server side (10.90 KB, text/plain)
2010-01-27 10:28 UTC, Jörg Sommer (mail address dead)
no flags Details
Fix-temp-file-perms-to-allow-reading-xattrs (1.16 KB, patch)
2010-08-12 00:29 UTC, Chris Dunlop
no flags Details
Patch to fix fake-super permissions (9.78 KB, patch)
2010-09-06 23:28 UTC, Chris Dunlop
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jörg Sommer (mail address dead) 2010-01-27 10:27:20 UTC
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
Comment 1 Jörg Sommer (mail address dead) 2010-01-27 10:28:46 UTC
Created attachment 5226 [details]
Output of strace of rsync on the server side
Comment 2 Matt McCutchen 2010-02-01 16:15:47 UTC
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.
Comment 3 Chris Dunlop 2010-08-12 00:29:16 UTC
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
Comment 4 Chris Dunlop 2010-09-06 23:28:55 UTC
Created attachment 5950 [details]
Patch to fix fake-super permissions
Comment 5 Chris Dunlop 2010-09-06 23:30:33 UTC
(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.
Comment 6 Wayne Davison 2011-01-01 19:05:23 UTC
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!