On Tue, Jul 09, 2002 at 02:36:22PM -0700, jw schultz wrote: > 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.
This might work. Will it still keep all my rwx bits intact? > > 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? Have you ever read bugtraq on a regular basis? They're coming out of the woodwork. -- Dan Stromberg UCI/NACS/DCS
msg04552/pgp00000.pgp
Description: PGP signature