On Tue, Jul 09, 2002 at 11:03:25AM -0700, Dan Stromberg wrote:
> 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?
Then don't use the --perms option.
>
> 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.
I don't get what you are doing. Where did these insecure
suid root files come from in the first place?
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
