rsync - Nov 2012 - [Bug 9377] New: acls ignored when using neither --perms nor --chmod

https://bugzilla.samba.org/show_bug.cgi?id=9377

           Summary: acls ignored when using neither --perms nor --chmod
           Product: rsync
           Version: 3.0.9
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
        AssignedTo: wayned at samba.org
        ReportedBy: chrysn at fsfe.org
         QAContact: rsync-qa at samba.org


summary
==========
when an acl that sets default permissions is configured on the receiving side
of an rsync transmission, those permissions get overruled by explicitly
applying the umask to the mode of a newly created file instead of letting the
os figure out how to set the modes. (having the operating system evaluating it
is the usual way umask, and is compatible with acls).

example
========
in the following example, it is assumed that umask is 022 and that /tmp is
mounted -oacl.

* mkdir and cd to /tmp/dest, do `setfacl -dm g::rwx .`
* `mkdir test` will create a 775 directory, as would be expected due to the
configured acl. the syscall issued is `mkdir("test3", 0777)`.
* at /tmp/src, `mkdir test2`. its permissions don't matter as we won't
send
them.
* there, `rsync -r . /tmp/dest`. the syscalls issued are
`mkdir("test2",
0700)`, `chmod("test2", 0755)`.

as a result, /tmp/dest/test2 is 0755 instead of 0777 as seen in /tmp/dest/test.

explanation of current behavior and suggestions
=============================================
the "create restrictive, then chmod" approach is reasonable when
syncing with
--perms in situations where data is created in 0000 directories (data inside
gets created, and the directory is then set 0000). it is also reasonable then
and with --chmod because any default permissions are meant to be overridden.

if neither --chmod nor --perms is given, the behavior should be altered to
create directories 0777 (as it is done by mkdir) and rely on the operating
system for interpreting umask, which can then apply other defaults too.
situations like files in 0000 directories can then not occur at all unless the
umask is set extremely restrictively (eg 0777), in which case whoever set the
umask hopefully knew what that does and might even expect things not to work.

(part of this was developed together with BasketCase on freenode/#rsync).

further reference
============
this problem was discovered in the context of git-annex at
<http://git-annex.branchable.com/bugs/acl_not_honoured_in_rsync_remote/>.
a
similar problem is present in `mkdir -p` as described in
<http://savannah.gnu.org/bugs/?19546>; there, it was not fixed but is just
being worked around, as mkdir tries to strictly implement a posix spec that was
written before acls were created, and prescribes explicitly applying a umask.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=9377

--- Comment #1 from chrysn at fsfe.org ---
in the mean time, coreutils have fixed their behavior of `mkdir -p` in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14371 , which might be useful when
going about this bug.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.