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

[Dan Stromberg]

On Sat, Jul 13, 2002 at 10:22:29AM +1000, Martin Pool wrote:
> On 12 Jul 2002, Dan Stromberg <strombrg at nis.acs.uci.edu> wrote:
> 
> > Because when we update, for example, bash, everbody's bash is going to
> > die on them if we don't keep around backups (segfault as you demand page
> > from a binary that has Mostly the Same Stuff in Different Places).
> 
> rsync creates a new file, and then atomically moves it into place on
> successful completion.  You should never end up with the file being
> part-changed, assuming you don't use --partial or -P.  

This should be sufficient to give .nfs* files then.

> It does not normally unlink as such, although I think it might try to
> use that as a big hammer if the rename fails.
> 
> So up until the file is completely transferred and the replacement
> takes place, everyone will keep seeing the old file.  Afterwards,
> people who had the old file open will keep seeing it, and people who
> open the new one will get the new one.  
> 
> This is, as far as I know, the same approach and the same semantics
> that most unix software-distribution systems, such as dpkg or rpm,
> will give you.
> 
> It may break on systems (like HP-UX?) that don't let you rename or
> remove a file while it's being executed.  I don't know what you're
> meant to do there, except shut down everything on the machine.
> Presumably you don't have one of those or -b would be failing.

We can rename running executables ok.

> > Or does rsync unlink and recreate rather than overwriting?  In that
> > case, we might just end up with a bunch of .nfs* files if we don't keep
> > backups.
> > 
> > Rumor has it, however, that depending on the .nfs* mechanism doesn't
> > always work.  I haven't seen it fail myself, but one of the other guys
> > here, who's pretty experienced, sounds pretty convinced that it fails
> > sometimes.
> 
> It's possible that you can get .nfs* orphans, but only you can know
> whether they're common in your environment.  If I understand
> correctly, the only problem with that would be that the old, setuid
> text still hangs around in the .nfs file.

It's crucial that whatever backup mechanism we use, will work well.  If
we can't get that with rsync in one way another, we'll have to look for
another solution, or stick with the nasty old homegrown stuff we
already have in place.

I'm not sure what .nfs* does with set[ug]id.

Honestly, if Mike says .nfs* doesn't always work, I'm inclined to trust
him.  He's wrong sometimes, but not often.  The issue was that demand
paging would glitch from .nfs* for no good reason.

Our homegrown stuff has a way of renaming running executables in order
to work around the .nfs* problems - almost certainly because of
encountered .nfs* problems.

> I would be inclined to say that it's not rsync's problem if unlink()
> is unreliable, so just run a sillyrename reaper and be done.

I don't have a problem with rsync ignoring rename troubles.

> 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 considered this, but I wasn't sure NFS/TheKernel would allow demand
> > paging from an inaccessible binary on all of our supported *ix platforms
> > now and into the future.  Are you?  We currently support Linux, Solaris,
> > Irix and Tru64 presently, and may add and drop some in the future.
> 
> I suspect that any machines that let you rename or unlink in-use text
> files will not care whether they have an accessible name or not.
> Unfortunately experiment is probably the only way to tell.

Nod.  Or just avoid the issue by having nonset[ug]id backup files.  :)
Seems a safer bet, no?

-- 
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/20020715/fd776fcd/attachment.bin