Summary: acls ignored when using neither --perms nor --chmod
AssignedTo: [hidden email] ReportedBy: [hidden email] QAContact: [hidden email]
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).
in the following example, it is assumed that umask is 022 and that /tmp is
* 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
* 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).