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?

sudo make install


sudo su
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. Commented Dec 3, 2015 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.) Commented Dec 3, 2015 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). Commented Dec 3, 2015 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
    Commented Dec 3, 2015 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
    Commented Mar 10, 2020 at 7:02

4 Answers 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 install

# Finally, make the executable easily accessible to users
sudo ln -s /opt/package_name/executable /usr/local/bin/

There should be no reason to ever compile as the root user. Even if the package will ultimately be run as root, that shouldn't have anything to do with compiling.

If you must compile as root to get the compile to succeed, something else is broken. Probably file permissions to a library somewhere. Find the problem, don't take the easy road and use root just because you can!

In general, applications should never run as root. In unix, root access is needed to bind to ports lower than 1024, so consider using higher port numbers. Unless your application is specifically intended to aid in system-level or system admin functions, please don't run it as root!

Many applications today are running as root simply because it's easy to do. If it runs as root, you don't have to worry about user/group file-level access control, or other OS-level security components. Root will "just work"... but it's the cheap and lazy way to do it, and puts the systems running your application at risk.

Run your application as an unprivileged functional account (ie. like others do... apache, websphere, mysql, etc). Avoid actually running as root. Please!


./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. Commented Dec 4, 2015 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. Commented Dec 4, 2015 at 2:07

Traditionally, we'd install packages like these into /usr/local, which is set up with mode 2775 and gid set to the group of users who are allowed to install software. Subdirectories also have the same setup.

Software is actually installed below /usr/local/DIR, and then symlinked into /usr/local/{bin,sbin,lib,...} using GNU Stow. If you want split responsibility for "compiling" and "actually making available", you can also give a separate gid to /usr/local/DIR.

Then for the actual installation, no root permissions are necessary.

If you have two groups, "software" and "install", one-time setup is

# mkdir -p /usr/local/DIR
# chgrp -R install /usr/local
# chgrp -R software /usr/local/DIR
# find /usr/local -exec chmod 664 {} \; -type d -exec chmod 2775 {} \;

Then, any user in the software group can compile and install to the staging area:

$ ./configure
$ make
$ make install prefix=/usr/local/DIR/package-1.0

Any user in the install group can make a package from the staging area available:

$ cd /usr/local/DIR
$ stow package-1.0

From a security point of view, this is not an absolute barrier -- any user in the software group can modify software after it has been installed, and it is likely that root will occasionally run stuff from /usr/local, so this is more a protection against stupid mistakes and a way to have non-root users provide software for others.

So this isn't a protection against inside threats. Look at your threat model and see where on the risk vs convenience axis you want to be.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .