The Samba-Bugzilla – Bug 5147
Read-only files that have changed xattrs fail to allow xattr changes
Last modified: 2010-08-21 16:16:52 UTC
When sending files with the --xattrs, if a file is read-only and has new extended attributes, a non-root receiving user can fail to set the new attributes.
One work-around for 3.0.0 is to use --fake-super on the receiving side (which is only an acceptable option when doing backups using a non-root user).
This bug occurs even if the file doesn't exist (thus newly created) on the target. This suggests that setting xattrs needs to be done before any chmod() or ACL is set.
The --fake-super work-around doesn't seem to work either.
A temporary file is created on the target with read-only permissions in open_tmpfile() (reciever.c). That prevents the faked super user to change attributes even though she owns the temporary file.
Temporary files should be created with mode 0600 (the same as when creating the file "inplace"). Correct attributes and modes (in that order) are set later in finish_transfer(), as the comment in open_tmpfile() before do_mkstemp() says already. Mode 0600 should also be used in the call to robust_rename() from finish_transfer().
Note that this will not fix a similar problem when read-only files are modified in place or when files in a read-only directory are created (either because they were created in the source, or they were modified and temporary files are created). A correct solution here should perhaps involve resetting the mode to 0600 before modification and setting it back to either the original mode or to the mode of the source file/directory afterwards. I have no idea how difficult that may turn out, though.
I'm checking in a fix that ensures that the temp file in receiver.c always gets created with S_IWUSR (0600) set. I've also changed the copy_file() code to ensure that that a file that will get tweaked by --xattrs also has S_IWUSR set.