On Mon, 24 Mar 2008 12:08:30 -0400, Dimi Paun wrote: > > On Mon, 2008-03-24 at 12:23 +0100, Michael Schwendt wrote: > > Oh, interesting, then you're one of the very few who really ran into > > it. It was mostly a theoretical problem, because users had to define > > %buildroot themselves to get "rm -rf /" and also build as root. > > Hey, this happened many years ago (maybe '97), so I don't recall exactly > what I did, but I didn't have to go through too many hoops :) > > Regardless, my point is that it pays to think about interfaces and > encapsulation, and this one is such an obvious fsck-up that it should > have been painfully obvious from the very beginning. > > It's still surprising that it managed to resist for so long. The first buildroot sanity checks were added in the 90's already, too. For commands like "rpmbuild --buildroot / ..." you get an error. There's still a "backdoor", though: rpmbuild --define 'buildroot /' ... and no default buildroot. But you can shoot yourself into the feet also with a redefinition of other essential macros. More often than somebody got "rm -rf /" as superuser because of an RPM buildroot definition, I've seen users damage their installations because Makefiles and other build-scripts did not stay in a buildroot but modified the system installation directly (and e.g. removed files there). > What would happen if rpmbuild would define %buildroot by default, > and make it immutable? Then we could just sed through the .spec > files and nuke its definition from there... First find a solution where the default buildroot is easy to find by the packager (not a temporary solution where mkstemp usage leads to lots of similar buildroots that are not deleted automatically) but is also cleaned up automatically by rpmbuild -- unless it's explicitly requested not to clean it. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
