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





------- Comment #4 from matt at mattmccutchen.net  2008-05-08 12:46 CST -------
(In reply to comment #3)
> 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 am very wary of trying to second-guess users and administrators like this. 
(Here, let me "fix" your computer...)  A user who changes the permissions on a
collection of large files and then mirrors it somewhere is not going to be
happy about the job taking several times as long as usual.  We can certainly
try to raise awareness about the tweaking problem (perhaps Wayne could be
persuaded to send something to rsync-announce), but I think forcing a change to
a long-established default on people is not called for.

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

No, only the daemon configuration needs to be changed; the client is not
involved at all.  Bug 5449 simply requests the "way to enforce a correct
"--link-dest" option on the server" that you originally mentioned.

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

I don't know why one would use "cp -al".  I was thinking that the client would
upload to the module and then the post-xfer script would copy the module
contents to a backup set elsewhere using --link-dest, just as if the module
were the original source.

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

As I said, if you do not want to trust a properly configured daemon with direct
access to the previous backup, your alternative is to use a second copy.  If
you have a better idea, I would like to hear it (preferably on the list or in a
separate enhancement request).


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