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

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


sites-samba@carlthompson.net changed:

What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn|4561 |




------- Comment #3 from sites-samba@carlthompson.net 2008-05-08 08:14 CST -------
(In reply to comment #2)
> (In reply to comment #0)

> ...

> > 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 reason why I think it's a good idea to change the default behavior is
because doing so would "fix" current backup solutions that are out there
without any modifications. I also think it is a much more sane default and
can't think of any cases where it would cause undesired results. (But of just
because I can't think of any doesn't mean they don't exist!)

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

But of course these require changes to the use of the client and daemon and I
think it's a good idea to avoid that. It also is still vulnerable to the chroot
problem below.

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

Exactly. But if you are keeping a second copy there is no point in using
"--link-dest" because you are already doing a "cp -al" to make the copy.

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

The client may not not be able to write to the previous backup but a buggy or
exploited forked daemon could. So I don't think this is a good a solution and
is more complex.

> ...

Thanks, Carl.


--
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.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html