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

Dan Stromberg strombrg at
Tue Jul 9 11:20:04 EST 2002

On Mon, Jul 08, 2002 at 02:04:57PM -0700, jw schultz wrote:
> The default behavior should not modify files.  The general
> purpose is to have the copies be the same as the original.
> A general --chmod or --pmask option might be acceptable for
> modifying the permissions flags but would need to be applied
> in generator as well as reciever.

We're not modifying the content of files; we're eliminating security
holes.  Surely folks see the sense of this?

Important things shouldn't be hard to do (you shouldn't have to parse a
log and write a shell script to do what should be default behavior),
just as dumb things shouldn't be easy to do (EG, clicking on attachments
in lookout).

> For almost any case like this the way to deal with it is in
> the mount options.  For -s to be active and ownership
> preserved root has to be doing the transfer anyway.  Try
> mounting the filesystem -o noexec,nodev  That way the backup
> will have all the same permissions bits but there need be no
> worry about users abusing it if given access.

If you had ever seen something like the huge software library we give to
our clients, you wouldn't say this.  We simply must have set[ug]id, but
only for secure binaries.  Having an insecure setuid root ~ file is a
vastly larger problem than not being able to run some ~ file without
minimal sysadmin intervention first.

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 :

More information about the rsync mailing list