https://bugzilla.samba.org/show_bug.cgi?id=5448
[EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn|4561 | ------- Comment #3 from [EMAIL PROTECTED] 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