Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
the famous "./configure; make" command line
This should more correctly be ./configure && make
in order to prevent an existing Makefile from surprising you.
./configure && make
The famous "./configure; make" - my custom version
Posted Mar 27, 2008 0:50 UTC (Thu) by pr1268 (subscriber, #24648)
# ./configure && make && make install && (cd /usr/local/bin && find . -type f | xargs file | grep "not stripped" | cut -d':' -f1 | xargs strip --strip-unneeded) && (cd /usr/local/lib && find . -type f | xargs file | grep "not stripped" | cut -d':' -f1 | xargs strip --strip-unneeded) && ldconfig && sync
Anyone want to guess which Linux distro I use?
Posted Mar 27, 2008 1:31 UTC (Thu) by stevenj (guest, #421)
Posted Mar 27, 2008 1:50 UTC (Thu) by pr1268 (subscriber, #24648)
Not all source packages have install-strip. But, yes, I usually do look for that target after the ./configure script is finished.
Posted Mar 27, 2008 15:47 UTC (Thu) by rvfh (subscriber, #31018)
one where people compile as root... and I wouldn't recommend it.
Posted Mar 27, 2008 18:15 UTC (Thu) by pr1268 (subscriber, #24648)
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 184.108.40.206 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!
Posted Mar 27, 2008 20:17 UTC (Thu) by zlynx (subscriber, #2285)
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.
Posted Mar 27, 2008 21:04 UTC (Thu) by felixrabe (guest, #50514)
grep 'rm -rf' configure
Posted Mar 28, 2008 0:02 UTC (Fri) by pr1268 (subscriber, #24648)
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...
Posted Mar 28, 2008 22:22 UTC (Fri) by nix (subscriber, #2304)
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.)
Posted Mar 28, 2008 13:47 UTC (Fri) by DonDiego (subscriber, #24141)
The code needs not be intentionally malicious. Just imagine that a Makefile contains a line
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...
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds