Date: Wed, 1 Sep 1999 00:17:56 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: imp@village.org (Warner Losh) Cc: ftobin@uiuc.edu (Frank Tobin), freebsd-security@FreeBSD.ORG (FreeBSD-security Mailing List) Subject: Re: Not sure if you got it... Message-ID: <199909010717.AAA73783@gndrsh.dnsmgr.net> In-Reply-To: <199909010640.AAA16059@harmony.village.org> from Warner Losh at "Sep 1, 1999 00:40:41 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <Pine.BSF.4.10.9908311022370.45784-100000@isr4033.urh.uiuc.edu> Frank Tobin writes: > : 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. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909010717.AAA73783>