strip setuid/setgid bits on backup (was Re: small security-related rsync extension)
mbp at samba.org
Fri Jul 12 10:16:27 EST 2002
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
For your situation, it might work better to dump them all into a mode
700 backup directory.
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
I have been thinking about what general strategies software tools use
to address this problem of focus. They seem to be
1- Add a pile of built-in options (--strip-setuid) -- rsync's strategy
2- Build a common layer, and then variations on the program to suit
different purposes. I think rdiff-backup is kind of like this.
It has the advantage that end users who "just want to do backups"
or software distribution or mirroring don't need to deal with
3- Make the program call out to various scripts that can control its
behavior -- the CVS server is like this, for example, with loginfo
scripts and so on.
4- Make the program's interfaces and performance characteristics be
such that it can easily be controlled by a scripting language.
Subversion is trying to be like this. The --log-format proposal
for rsync goes in this direction, though needing a new socket for
each invocation rather cripples it.
5- Make the whole program intimately intermingled with a scripting
language, like emacs or (perhaps) Mozilla.
More information about the rsync