DO NOT REPLY [Bug 5448] Daemon parameter to prevent attribute tweaking

[samba-bugs at samba.org]

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


matt at mattmccutchen.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |enhancement
            Summary|rsync modifies files in     |Daemon parameter to prevent
                   |place even without --inplace|attribute tweaking
                   |specified                   |




------- Comment #2 from matt at mattmccutchen.net  2008-05-07 22:43 CST -------
(In reply to comment #0)
> rsync always modify files in place to reflect changes in permissions, ownership
> or group without regard to the "--inplace" option.

This behavior is not a bug per se: it is documented in the man page in the
second paragraph under DESCRIPTION.

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

I'm not sure it would be wise to change the default behavior to --no-tweak, but
it would certainly be useful to add a daemon configuration parameter to force
--no-tweak mode; I'll convert this bug to an enhancement request for such a
parameter.

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

Right; this would be solved by --no-tweak or a corresponding daemon parameter.

> 2a. A big problem with "--link-dest" is that it requires that the client
> machine be correctly configured to work.

I have entered bug 5449 for the ability to specify a link-dest dir on a daemon
in a way that is transparent to the client.

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

If you want to keep only one copy of the previous backup, clearly there's no
way the daemon can --link-dest from it unless it is inside the chroot; nothing
can be done about this.  Thus, if you are worried about bugs in the daemon, you
will have to keep a second copy just for the daemon, as you mention.

However, a bug-free daemon with the enhancements that we're discussing could be
configured so it would not harm the previous backup no matter what the client
does.  Specifically: the daemon link-dest parameter I'm envisioning would let
you locate the previous backup outside the module (but of course inside the
chroot).  With that arrangement and symlink munging, the client can't write to
the previous backup directly, and with a no-tweak parameter, the client can't
write via existing hard links in the module in the event that a backup is
interrupted and restarted.

> 2c. Lots of other problems and confusion related to "--link-dest" . (See
> Bugzilla).

I'm not sure why you mention this here, because if the bugs are in Bugzilla,
that means that we already know about them (or they are fixed).  By the way,
the link in your email matched a lot of bugs that have nothing to do with
--link-dest.  Here's mine:

https://bugzilla.samba.org/buglist.cgi?query_format=advanced&long_desc_type=substring&long_desc=--link-dest


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