rsync - Dec 2007 - DO NOT REPLY [Bug 5147] New: Read-only files that have changed xattrs fail to allow xattr changes

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

           Summary: Read-only files that have changed xattrs fail to allow
                    xattr changes
           Product: rsync
           Version: 2.6.9
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: core
        AssignedTo: wayned@samba.org
        ReportedBy: wayned@samba.org
         QAContact: rsync-qa@samba.org


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).


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

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





------- Comment #1 from bizwig at yahoo.com  2009-08-25 22:19 CST -------
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.


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

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


jan.kluka+bugzilla.samba.org at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kluka+bugzilla.samba.org
                   |                            |@gmail.com




------- Comment #2 from jan.kluka+bugzilla.samba.org at gmail.com  2009-11-18
07:02 CST -------
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.


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

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


wayned at samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Comment #3 from wayned at samba.org  2010-08-21 16:16 CST -------
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.


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