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

Dan Stromberg strombrg at nis.acs.uci.edu
Fri Jul 12 10:36:01 EST 2002


On Fri, Jul 12, 2002 at 02:59:11PM +1000, Martin Pool wrote:
> On 11 Jul 2002, Dan Stromberg <strombrg at nis.acs.uci.edu> wrote:
> 
> > > I don't get what you are doing.  Where did these insecure
> > > suid root files come from in the first place?
> > 
> > Have you ever read bugtraq on a regular basis?  They're coming out of
> > the woodwork.
> 
> Another question would be, why do you want to keep them around at all?
> Presumably so that people can undo the changes if something goes
> wrong?

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

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.

> For your situation, it might work better to dump them all into a mode
> 700 backup directory.

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.

> It seems like the overarching problem is different focusses: Dan wants
> rsync to be a software-distribution mechanism (which is certainly a
> good use for it), which which case stripping setuid bits is obviously
> quite desirable.  But for a bit-perfect backup tool, it's probably
> wrong.

For what it's worth, everything but the backup files is still bit
perfect in what I'm proposing, and the backup files weren't bit perfect
to begin with.

-- 
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/20020712/8d606851/attachment.bin


More information about the rsync mailing list