DO NOT REPLY [Bug 5448] New: rsync modifies files in place even without --inplace specified

[samba-bugs at samba.org]

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

           Summary: rsync modifies files in place even without --inplace
                    specified
           Product: rsync
           Version: 3.0.2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P3
         Component: core
        AssignedTo: wayned at samba.org
        ReportedBy: sites-samba at carlthompson.net
         QAContact: rsync-qa at samba.org


rsync always modify files in place to reflect changes in permissions, ownership
or group without regard to the "--inplace" option. The "--inplace" option is
supposed to regulate whether files to be backed up that are already found in
the destination directory are modified in place or simply used as the basis for
new files. Not being able to completely eliminate modifying files in place
greatly and negatively affects a very common use of rsync: backup systems that
create incremental backup snapshots using hard links. In such systems the
current behavior of rsync makes it a trivial exercise for a misconfigured or
compromised / malicious client to seriously damage or destroy all current and
prior backup snapshots in the set. The "--link-dest" option attempts to solve
the problem but adds serious problems of its own. Some of the problems I see
are:

1. The hard links and permission / owner / group change problem: This is a
problem that has been well known for many years. When using hard links to
implement snapshots (as most incremental snapshot backup systems that utilize
rsync do) when files are modified in place (as rsync always does for
permission, owner and group changes without any regard for the "--inplace"
option) those changes affect not just those files in the current backup but
also in all previous backups (since the last time the contents of the file were
changed). So if for example a client machine is compromised and the attacker
executes the command "chmod -R 666 /" the next time the rsync backup is
performed all of the backup snapshots become unreliable. This can also happen
if the filesystem is accidentally backed up and restored locally using a medium
that does not support permissions.

2. Problems with the "--link-dest" option: The "--link-dest" option was
apparently added to rsync to address the above problem but it does so in a way
that introduces vulnerabilities of its own.
2a. A big problem with "--link-dest" is that it requires that the client
machine be correctly configured to work. There is no way to enforce a correct
"--link-dest" option on the server. Not only does the client need to specify
the option but also its use of the option needs to exactly match what the
rotation / renaming scripts on the server expect or not-so-wonderful things
will happen (you can use your imagination). Configuration mistakes or malicious
users can wreak all sorts of havoc by omitting or playing with this option. Any
backup solution that requires the server to trust that the client is properly
configured in order for the server to work correctly is not reliable.
2b. Another big problem with "--link-dest" is that when used as documented and
intended there is only one copy of the previous backup and it cannot be
protected from the forked daemon by chroot!  The daemon must have direct access
to the one and only good copy of your data so a bug, exploit or malicious
client can easily clobber it. Any backup solution that requires the server to
trust that the client is properly configured in order to protect the integrity
of previous backups is not reliable. On the other hand if the linked copy of
the backup is created after the rsync daemon has finished (i.e., not using
"--link-dest") your previous backups can be protected from the daemon by chroot
with only a copy of the data acted upon by the daemon.
2c. Lots of other problems and confusion related to "--link-dest" . (See
Bugzilla).


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