Run the following in an empty directory, putting some username on your system in place of $USER: mkdir src dest echo foo >src/file echo barbar >dest/file setfacl -m u:$USER:rw- dest/file rsync -r src/ dest/ Since permissions are not being preserved, rsync loads the old permissions of dest/file into the file list and applies them to the new dest/file. Rsync should treat the access ACL in the same way, but it does not, so the old access ACL of dest/file is lost. The mask permission bits are applied as group permission bits, possibly granting access to undesired users. If permissions but not ACLs are to be preserved, I'm not sure what rsync should do. Since permissions and ACLs are inseparable from a security point of view, perhaps we should get rid of this odd case by making --perms preserve ACLs and throwing out --acls.
It makes sense to me that if we aren't copying permissions/acls, that the new file should preserve the current file's permissions/acls. It might also make sense to include ACLs in the definition of --perms in a future rsync as long as there is a protocol-number bump that determines if we can send the ACLs or not, and rsync outputs an error when ACLs are being dropped (i.e. some are found, and we couldn't preserve them due to the protocol # being too low).
In the same way, rsync loses xattrs on recreated files. This might be the desired behavior in a few cases; for example, an xattr indicating that a destination file has been backed up should be lost so that the new destination file gets backed up.
*** Bug 7773 has been marked as a duplicate of this bug. ***
In bug 7773, Aleksey Tsalolikhin pointed out that user and group ownership are lost too. I'm broadening this bug to cover all attributes.