The famous "./configure; make" - my custom version [LWN.net]

The famous "./configure; make" - my custom version

Posted Mar 27, 2008 18:15 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

What's the harm in compiling as source code as root? I've heard of some urban myth where compiling the Linux kernel as root used to throw a segmentation fault, but that was fixed ages ago. Granted, my example above is not compiling kernel source, but rather some user space application.

FWIW I run that chain of commands in a Konsole window, logged into KDE as a non-privileged user, and a su - in the terminal. I'm unsure of any (obvious) security issues in this configuration as I'm sitting right there at the physical computer.

And, just the other day I attempted to compile kernel 2.6.24.4 as non-privileged user and got some weird errors during the first-running scripts (i.e. after make menuconfig). Sure, I'll admit I might be doing it "wrong" (or in a fashion you don't recommend), but how might I do it "right"? Thanks!

The famous "./configure; make" - my custom version

Posted Mar 27, 2008 20:17 UTC (Thu) by zlynx (subscriber, #2285) [Link]

Compiling as root has some hazards because of how complicated configure and make scripts can
be.  It isn't that there might be a hidden trojan in the code (after all you're going to run
make install anyway right), but that the build scripts might accidentally do bad things.

For example, I once saw a makefile try to delete and rebuild some system library because it
was listed as a dependency that got make's automatic target rules all excited.  It only tried
that on certain configurations of machine, never the developer's so he never saw the problem.

The famous "./configure; make" - my custom version

Posted Mar 27, 2008 21:04 UTC (Thu) by felixrabe (guest, #50514) [Link]

Well, you probably don't run grep 'rm -rf' configure every time before you compile something, right? ...

The famous "./configure; make" - my custom version

Posted Mar 28, 2008 0:02 UTC (Fri) by pr1268 (subscriber, #24648) [Link]

Well, you probably don't run grep 'rm -rf' configure every time before you compile something, right? ...

I can't say I've ever done that. Nor have I experienced anything remotely similar to zlynx's scenarios.

Although I do understand the risks of overusing the root account, I only build sources I consider trustworthy (usually tarball projects downloaded from SourceForge or KDE), but even these reputable source repositories may let some malicious code slip by...

I also admit I'm "going against the grain" in the context of accepted make/build practices; I'll try to figure out how to adjust permissions and/or ownership such that I can do ./configure and make as an unprivileged user...

The famous "./configure; make" - my custom version

Posted Mar 28, 2008 22:22 UTC (Fri) by nix (subscriber, #2304) [Link]

chown your build tree to the unprivileged user, build as normal, `make 
install' as root or (if you're paranoid) use `fakeroot' or some similar 
package to install and then deal with the resulting miniature root tree 
using GNU stow or something similar.

(Rarely (very rarely) one encounters packages that write stuff to the 
build tree during the `make install' process, so you might need to be root 
to *remove* it if you chose to do the final installation as root.)

The famous "./configure; make" - my custom version

Posted Mar 28, 2008 13:47 UTC (Fri) by DonDiego (subscriber, #24141) [Link]

The code needs not be intentionally malicious.  Just imagine that a Makefile contains a line
like

  rm -rf $(VARIABLE)/path/to/somewhere

Now if $(VARIABLE) happens to be empty (perhaps only in your nonstandard configuration and not
on the developer's machine), pray that there is nothing important below /path/to/somewhere ...

That's just a simple example, it's easy to come up with more.  It's not so much about
protection against malice, but protection against accidents.  Accidents do happen, it's a fact
of life.  If you want to drive without a seatbelt, all I can wish you is good luck...