4

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
  • 2
    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
  • 1
    I don't see the logic of typing an extra word all the time. I always use root when doing something on linux servers. – Overmind Mar 10 at 7:02
4

There are two different situations:

1. You are going to run the software as root

In this case you should really trust the source code before using it. Either by auditing it, or by trusting the author and the delivery method.

If you are going to be recompiling the code, then I think the source files should be owned by root, so that an unprivileged user cannot modify them. And if the source tree is owned by root, then you will have to compile as root. If you trust the source code more than you trust your users, then that is the safer option.

2. You are going to run the software as a user

Ideally you should trust the source code before giving it to your users. But let's say that criterion is relaxed, and you don't fully trust the code.

Then it's not a good idea to compile or run the software as root.

Traditional installation, only partially as root

You can compile the software as any user, e.g. by running ./configure && make

But you might still need to run sudo make install to make the compiled code visible to other users. In this case, you only need to audit the Makefile before running it.

Build a package for root to install

Alternatively, on Debian and derivatives you can use something like equivs-build or fakeroot equivs-build which will create a dpkg which you can then install as root.

But be aware that packages may have post-install scripts which could do anything with root privileges. So this may also need auditing.

Safest: Install the software to a non-system folder

With this approach, root's involvement is minimised:

# Create a folder as root, and give one of your users control over it
sudo mkdir /opt/package_name
sudo chown user1:user1 /opt/package_name

# Now do compilation and installation as user1
./configure --prefix=/opt/package_name
make
make install

# Finally, make the executable easily accessible to users
sudo ln -s /opt/package_name/executable /usr/local/bin/
| improve this answer | |
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).

| improve this answer | |
  • 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.