From owner-freebsd-security Wed Sep 1 0:18:42 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 A807C15459 for ; Wed, 1 Sep 1999 00:18:39 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id AAA73783; Wed, 1 Sep 1999 00:17:56 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909010717.AAA73783@gndrsh.dnsmgr.net> Subject: Re: Not sure if you got it... In-Reply-To: <199909010640.AAA16059@harmony.village.org> from Warner Losh at "Sep 1, 1999 00:40:41 am" To: imp@village.org (Warner Losh) Date: Wed, 1 Sep 1999 00:17:56 -0700 (PDT) Cc: ftobin@uiuc.edu (Frank Tobin), freebsd-security@FreeBSD.ORG (FreeBSD-security Mailing List) 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 > In message Frank Tobin writes: > : 3) Use chflags -R , 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. > > And might also have a race condition in it, since if someone adds a > flag after the chflags -R has gone over it, rm will not be able to > remove the file. And just how would you implement rf -rF that this window was eliminated? It would be greatly narrowed, but it would be next to imposible to eliminate unless you started to do mandatory locking on directories, or implementing an additional system call that was ``unlink regardless of flags'', or bent the current unlink/rmdir to take additional options. Infact, how does rm -rf deal with someone possibly comming along with a chmod 0 filename stuck in a nice tight loop??? rm is full of race conditions, especially when run with -i :-). Has anyone else seen the point I raise about creeeeeeping featuresism, and perhaps understand why I get so vocal about some of this stuff? Implementations have to be very carefully planned, studied for problems, tested for problems, and then looked at by ``devils advocates'' before they can be considered real. -R can never be made race safe until mandatory locking is implemented. > > : 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). > > 5) find -delete should take all measures that it can to remove the file. I strongly disagree. I didn't even know find had a -delete option, of I want find to delete for me I pipe to xargs rm. > > The whole file flags thing was a cool idea, but it is a PITA and > likely shouldn't have been implemented the way it was:-( Can we have a knob to turn it off TOTATALLY OFF, please please please. Even if it's compile time. It has become such a PITA it has created security problems, probably more DOS problems than it ever solved. -- 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