2

When I am compiling software for local installation, what factors should I take into consideration when deciding whether to compile as root or to compile under my regular user account?

./configure
make
sudo make install

or

sudo su
./configure
make
make install
  • Which flavor of Unix do you use? Tarballing is not a safe or recommended practice. There are package management systems and autopackagers that let you make a package from a tarball. – Deer Hunter Dec 3 '15 at 8:37
  • I use Debian GNU/Linux. But I still occasionally find software that isn't pre-packaged. (I tend to use a prefix and something like stow to keep files neatly isolated.) – joeytwiddle Dec 3 '15 at 16:38
  • 1
    A single system of packages is there for a reason: it takes away the ability to mess things up royally. With fpm rolling up a new .deb is a breeze, no need to compile as root (still, executing things on your computer leaves you vulnerable to privilege escalation and compiler bugs, but that's much more tractable than the tarball stuff). – Deer Hunter Dec 3 '15 at 17:21
  • 1
    Is there any reason you need to compile as root? installing will usually require root, since you write to protected directories, but compiling is a separate issue. – amccormack Dec 3 '15 at 17:48
  • Is your system a system on production? Compilations are usually done on maintenance systems. – ott-- Dec 3 '15 at 21:57
1

./configure means: run the shell script (or binary) named configure in the current directory. You'll execute whatever is in that script, which could be: well, anything you can imagine. Usually configure scripts are auto-generated from trusted inputs, but if you're downloading something random from the Internet, there's absolutely no guarantee that configure can be trusted.

make also runs a script, probably makefile in the current directory which is written in the make language. It can also do pretty much anything.

Practically: if you compile a program once as root, then as you fix compile problems you will need to keep compiling as root, because a normal user won't be able to clean up all the intermediate files that are generated. So it's not uncommon to see someone recommending you build as root because one time it worked for them when building as user didn't, generally because they hit this sort of situation and didn't realize it.

If you don't trust the source (and I imagine you are, since you're posting on Security instead of Unix Stack Exchange), you can compile (and install if you want) and run within a chroot, container or VM, so you never need to directly give the software root on your main system (though programs can theoretically break out of any of those jails).

  • Yes, this is along the lines of what was bugging me. It makes me think I should compile under a user with less privileges than my regular account, which is sudo capable. I could even make install as that user, to a suitable location. – joeytwiddle Dec 4 '15 at 2:06
  • 1
    But there's a kind of false security here - an attacker could almost as easily put malicious code in the compiled software instead of the build scripts, and I will still end up running it as my user or as root. On balance of probabilities, compiling and running with as few privileges as possible seems wise. So your chroot suggestion is welcome. Perhaps docker would be a safer alternative, and a bit lighter than a VM. – joeytwiddle Dec 4 '15 at 2:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.