Date: Tue, 31 Aug 1999 10:56:40 -0500 (CDT) From: Frank Tobin <ftobin@uiuc.edu> To: FreeBSD-security Mailing List <freebsd-security@FreeBSD.ORG> Subject: Re: Not sure if you got it... Message-ID: <Pine.BSF.4.10.9908311022370.45784-100000@isr4033.urh.uiuc.edu> In-Reply-To: <199908311450.IAA11239@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh, at 08:50 on Tue, 31 Aug 1999, wrote: > : IMHO, rm should not know about flags at all. chflags knows about flags, > : and if we ever get acl's rm should not be tought about them either, > : some other command (acl(1) anyone) will know how to deal with them. > > Yes, but if force doesn't mean try your best to delete it, then it is > kinda useless... There are times that policy is to kill everything, > flags to the contrary non-with-standing. 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. 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. 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). 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). Personally, I vote for solution 1), adding a -F flag. Since we added flags to the filesystem, we should have a means to forcibly override them also (where appropriate), when we know we have to override them. Since I don't like 3) and 4), and 2) is dangerous, I have to settle on 1). One problem with my position, though, is that we have to consider what happens if we add flags like 'noread'. Should cp(1) be able to override this? Currently, this is just a hypothetical situation, but one should at least try to be a little consistent in design (which is why I love having -R available for most operations; no other OS seems to have -R for tools such as grep). -- Frank Tobin "To learn what is good and what is to be www.neverending.org/~ftobin valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus PGPenvelope = GPG and PGP5 + Pine PGP: 4F86 3BBB A816 6F0A 340F www.neverending.org/~ftobin/resources.html 6003 56FF D10A 260C 4FA3 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?Pine.BSF.4.10.9908311022370.45784-100000>