strip setuid/setgid bits on backup (was Re: small security-related rsync extension)
strombrg at nis.acs.uci.edu
Fri Jul 19 12:40:01 EST 2002
On Fri, Jul 19, 2002 at 12:15:01PM -0700, Dan Stromberg wrote:
> > My understanding of sillyrename, from memory and a brief perusal of
> > the kernel source (I don't have Callaghan here), is as follows:
> > It is a purely client-side behaviour, to handle the fact that Unix
> > files may be still open when unlinked. This relies on Unix having an
> > in-memory use count, in addition to the on-disk link count. The
> > problem is that the NFS server may reboot while the client has the
> > file open, therefore losing its in-memory use count, and causing the
> > file data to be garbage-collected by fsck. As a workaround, deletes
> > or link-replacement on the client for a file still in use are handled
> > by moving that file to a temporary name, so that from the
> > point-of-view of other clients the file has gone. When the use count
> > drops to zero, the client removes the .nfs file. If the client
> > crashes or the net is partitioned before the use count goes to zero,
> > then the .nfs file may remain indefinitely, which is why you need a
> > reaper run from cron.
> > If this is wrong please explain how.
> > This is, incidentally, a much better solution for replacing in-use
> > files than rsync's backups, because it only affects in-use files, and
> > they are gc'd when no longer in use. Replacing local files and
> > letting the kernel handle it is even better, because it can never
> > leak.
> 1) This is an interesting, but quite irrelevant implementation detail
> with respect to the subject matter at hand. If you like, I can now tell
> you something you didn't know. Maybe I'll score some points. I'll make
> sure it's irrelevant, too.
Many apologies. If we update on the nfs server, as we've intended all
along, we should have no .nfs* files.
This really doesn't change the fact that rsync shouldn't violate the
principle of least surprise, however.
Dan Stromberg UCI/NACS/DCS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
Url : http://lists.samba.org/archive/rsync/attachments/20020719/ab7badb2/attachment.bin
More information about the rsync