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.