On 11 Jul 2002, Dan Stromberg <[EMAIL PROTECTED]> 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? 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 wrong. 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 to date. 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. -- Martin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
