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


sites-samba at carlthompson.net changed:

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




------- Comment #3 from sites-samba at 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.