strip setuid/setgid bits on backup (was Re: small security-related rsync extension)

Dan Stromberg 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
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.samba.org/archive/rsync/attachments/20020719/ab7badb2/attachment.bin


More information about the rsync mailing list