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 #5 from sites-samba at carlthompson.net  2008-05-08 15:07 CST -------
(In reply to comment #4)
> (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...)

I understand that but I think the reality is that the current default is
behavior that is unwanted in real-life and causes serious security
vulnerabilities.

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

This is an edge case where things would be a little slower. But this is
actually an argument _for_ my idea because this user's previous backups would
be broken by the current behavior. If the user really wants the files modified
in place regardless of the risk it makes sense to me for the user to explicitly
request that by using the "--inplace" option.

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

Normally I would agree with you but I have pointed out multiple cases where the
current behavior causes problems and can compromise the integrity of every
backup in the set making the entire set unusable. To me, the ability of a
malicious user on a compromised host being able to easily make all of the
backups on the server unusable is a pretty strong argument for changing the
default. Further, I can't think of a use case where the change would produce an
undesired end result. If you can think of such a real-world case then of course
it would be different.

I think it's best to look at it as a bug / security fix.

> ...

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

Because I think that one "rsync" run and one "cp -al" copy would be faster than
two "rsync" runs.

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

_This is_ my better idea! Fix rsync to not modify files in place without
"--inplace" and never use "--link-dest" but use server side scripts intead.


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