strip setuid/setgid bits on backup (was Re: small security-related rsync extension)
strombrg at nis.acs.uci.edu
Tue Jul 16 07:28:01 EST 2002
On Tue, Jul 16, 2002 at 10:50:03AM +1000, Martin Pool wrote:
> On 15 Jul 2002, Dan Stromberg <strombrg at nis.acs.uci.edu> wrote:
> > The issue was that demand
> > paging would glitch from .nfs* for no good reason.
> That is an extremely unconvincing argument for changing rsync.
> > > Is it possible to just rsync onto the NFS server, rather than onto the
> > > clients? That would probably be faster, and avoid sillyrename.
> > Yes, of course. This has been our intent all along.
> I don't think you will get sillyrename files by operating only on the
> server. A quick scan of the Linux 2.4.18 kernel source shows that
> sillyrename is only done in the client, which agrees with my understanding
> of the role they play in NFS. So the whole discussion is moot.
If by sillyrename, you mean busy text files are renamed to .nfs*, then I
think you're missing how it works yourself, I'm sorry to say.
You just unlink something on the server, and it happens, like magic.
Maybe that happens on the client side - but that's really beside the
point. Rename will probably do just as well.
.nfs* may well suffer from the same "the backup file is still setuid"
I'm finding it hard to see why this makes the issue moot.
I'm also finding it hard to understand why security might be so
unimportant to you. I seriously wish you'd read bugtraq for a few
months before making such a short sighted decision. Bear in mind that
sendmail is now loaded with stuff like dont_blame_sendmail just to get
/var group writable, because people were blaming all kinds of nutty
stuff on sendmail - while this is actually a legitimate problem of
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/20020716/cacd0fb3/attachment.bin
More information about the rsync