Date: Wed, 01 Sep 1999 06:53:51 +1000 From: Greg Black <gjb-freebsd@gba.oz.au> To: Frank Tobin <ftobin@uiuc.edu> Cc: FreeBSD-security Mailing List <freebsd-security@FreeBSD.ORG> Subject: Re: Not sure if you got it... Message-ID: <19990831205352.21053.qmail@alice.gba.oz.au> In-Reply-To: <Pine.BSF.4.10.9908311022370.45784-100000@isr4033.urh.uiuc.edu> of Tue, 31 Aug 1999 10:56:40 EST References: <Pine.BSF.4.10.9908311022370.45784-100000@isr4033.urh.uiuc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> Correct me if these analyses are incorrect, but it seems we have a couple
> options here to remove entire structures with flags inside of it:
>
> 1) Give rm -F. This would perform as per the proposal. The arguments
> against this seem to be that this breaks traditional unix philosophy of
> atomic elements.
>
> 2) Have rm -rf automatically remove flags. The arguments against this is
> that some flags could be used as protectors/dummy-resistant flags, to
> prevent accidental removal of file.
I'm against the first two for the reasons given.
> 3) Use chflags -R <noAllFlagsOrSuch>, followed by rm -rf. This two step
> process is consistent with unix philosophy. This is probably the cleanest
> (traditionally) solution. However, it causes two disk passes instead of
> one.
This one should be expressed more like:
rm -rf dir || {
echo second pass to remove flags
chflags -R nouserflags dir
rm -rf dir
}
This way, it's only a single pass in the common case where there
are no files with flags that stop the rm. The chflags pass will
only find the few files with flags set as the rest have already
been removed. This makes clear what is happening and at least
acknowledges that certain flags are *supposed* to stop rm.
> 4) Use find(1) with -exec chflags and rm. This has the downside of many
> processes getting started (one chflags and one rm for each node), and
> again, more disk usage (we don't all use SCSI yet).
This one sucks.
> Additionally, solutions 3 and 4 have downside of having to train users to
> remember to use such a multiple-step pass in scripts and such; if these
> implementations are chosen, the need to remove flags with chflags(1)
> should be documented in the manpage of rm(1) under the -f option (or
> BUGS).
The users who need to learn how to deal with flags had to learn
how to enable them in the first place. There's not much new
training to do, and it can be managed by minor additions to the
relevant man pages.
One additional reason not to put flag-changing capabilities in
rm is that flags are, by design, intended to prevent certain
uses of rm. For instance, if an admin wants to put en empty
.rhosts file in users' home directories he can do this by making
it root-owned with the uchg flag. The user can still write in
(and remove files from) his home dir, but he cannot remove that
file.
The thing that is really wrong with the flags is the absurd
names they have been given as in these two examples:
* nodump sets a flag, dump unsets it
* uchg sets a flag, nouchg unsets it
It would have made much more sense if the second one was changed
so that:
* nodump still sets a flag, while dump unsets it
* nouchg sets a flag ("user flag for no change"), uchg unsets it
Of course, changing things like this once the bad design has
escaped is non-trivial.
--
Greg Black -- <gjb@acm.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990831205352.21053.qmail>