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

[Martin Pool]

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.  

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.

> 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.

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.

Is it possible to just rsync onto the NFS server, rather than onto the
clients?  That would probably be faster, and avoid sillyrename.

> 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.

-- 
Martin