From owner-freebsd-security Tue Aug 31 0:22: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id E30BA15A11 for ; Tue, 31 Aug 1999 00:22:01 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id AAA68164; Tue, 31 Aug 1999 00:20:40 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199908310720.AAA68164@gndrsh.dnsmgr.net> Subject: Re: Not sure if you got it... In-Reply-To: <199908310200.MAA01906@godzilla.zeta.org.au> from Bruce Evans at "Aug 31, 1999 12:00:57 pm" To: bde@zeta.org.au (Bruce Evans) Date: Tue, 31 Aug 1999 00:20:40 -0700 (PDT) Cc: imp@village.org, dynamo@ime.net, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> I'd also like to have a new flag to rm. -F. One -F will be > >> chflags nouflags foo ; rm -f foo > >> while two -F will be > >> chflags 0 foo ; rm -f foo > > > >I have a problem with this, it means updating 1 more chunk of code > >should the set of items in uflags change. > > Interesting point. Support for removing user flags has already rotted > in rm. The UF_NOUNLINK flag was added on 1997/06/02 but rm -rf still > doesn't clear it. Actually I think that was done on purpose. Since UF_NOUNLINK is to protect the user from removing the file it would kinda make since that rm -rf should bitch loudly when asked to rm a UF_NOUNLINK flagged file shouldn't it? 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. > Support for the nounlnk flags is also broken in chflags and ls. > The flags are negative logic, like UF_NODUMP, and this is consistently > handled backwards (nodump was only backwards in the manpage). Thus you > have to say `chflags uunlnk ...' to set the _NO_ uunlnk flag, and ls > tells you that the uunlnk flag is set despite there being no such flag. > The abbreviation uunlink as uunlnk doesn't help. Can I simply state that ``flags'' are broken in general, the concept was not well though out as to orthagonality, implementation impacts and completeness. It's a poor mans attempt to bandaid in 6 or so fixed valued acl's. I know it is all we've got, and I suppose that something is better than nothing, _until_ (and it has just been pointed out again how to use these for DOS) they cause security problems. As far as I am concerned the whole flags thing should die a quick and ugly death as non functional bloat with serious security concerns being the #1 reason. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message