This is a history related question of a sense, tightly related to the use cases of Linux. Am open to closing it if it's off topic.

Why is the default to always use sudo when installing with package managers even if there is no technical necessity for it?

i.e. say I want to install vim on a multi user server, and getting sudo access is a bureaucratic pain. Until the appimages (or similar) the only choice would have been to compile and make install in a home location.

Are there any historical reasons for why this would be so? Or am I missing some technical reasons behind the scene?

  • Look at the mount man page – noexec means it may have been difficult for you to run a (possibly CPU-expensive) binary from your home directory on a shared system even if you had access to a compiler. Dec 5, 2019 at 12:25
  • I don't know wtf "appimages" are, but for the "or similar" part it has ALWAYS been possible to use as install binaries as a regular user. I have some 20 or 30 versions of firefox, jdk and chrome, and I've never compiled any of them from source. As to why sysadmin-tools like package managers should be run by the ... sysadmin, I don't think that it warrants any discussion: good luck designing a package manager where when user jack calls apt-get install vim, it gets back: "no need to install vim; your friend bill has already installed it in /home/bill/.local/".
    – user313992
    Dec 5, 2019 at 12:30
  • @mosvy install binaries as a regular user. How? By manually copying a statically compiled binary to your home dir and executing it? your friend bill has already installed it That's not the use case I'm aiming at is that bill and jack both have their own separate binaries (with the libs that were missing on the system) Dec 5, 2019 at 12:53

1 Answer 1


I will preface that this answer is more specifically about why sudo has been necessary to package management.

Requiring system level privileges to complete system level tasks makes sense. Historically, Linux, coming from a Unix-like heritage, is designed with a multi-user set up in mind. To prevent user's from messing with each other and to better manage control over the system, a system administrator is empowered to be able to control and limit user's access to root or system level activities.

Here is a brief introduction of sudo from the offical sudo website (emphasis mine):

Sudo ("substitute user do") allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis, it is not a replacement for the shell. Its features include:

  • The ability to restrict what commands a user may run on a per-host basis.

  • Sudo does copious logging of each command, providing a clear audit trail of who did what. When used in tandem with syslogd, the system log daemon, sudo can log all commands to a central host (as well as on the local host). At CU, all admins use sudo in lieu of a root shell to take advantage of this logging.

  • Sudo uses timestamp files to implement a "ticketing" system. When a user invokes sudo and enters their password, they are granted a ticket for 5 minutes (this timeout is configurable at compile-time). Each subsequent sudo command updates the ticket for another 5 minutes. This avoids the problem of leaving a root shell where others can physically get to your keyboard. There is also an easy way for a user to remove their ticket file, useful for placing in a .logout file.

  • Sudo's configuration file, the sudoers file, is setup in such a way that the same sudoers file may be used on many machines. This allows for central administration while keeping the flexibility to define a user's privileges on a per-host basis.

Now to get to your question of package management requiring sudo. That is not always the case. Here is a relevant AskUbuntu post covering this topic. As user Braiam points out apt-get requires sudo because many times when installing a package you need system level access to install and write to system directories.

However as he also points out one can use apt-get to download and install packages to locations a non-privileged user has access to. Examples include using apt-get download or just plain old wget to download a package to your current directory and then to use dpkg to install the package.

The issue with this is that from an administrative stand point this is a headache. Users will be using unnecessary amounts of disk space by each having a copy of a piece of software and its dependencies, certain software can at times be malicious or behave in a manner that introduces vulnerabilities or other issues, and allowing free reign of installation does not allow one to quickly audit and update what software is on the system. Package managers allow central control and the ability to audit and trust where packages come from.

Additionally, as user Ulrich Schwarz points out, the home directories may be mounted to a partition with a noexec flag meaning:

...it may have been difficult for you to run a (possibly CPU-expensive) binary from your home directory on a shared system even if you had access to a compiler.

I will also link to this U&L stack exchange post asking about "Why do I have to use sudo for almost everything?". I believe the answers to sufficiently back up my point in this post. You can also learn more about the history of sudo on Wikipedia.


sudo was developed in the early 1980's to allow users to run programs with the security privileges of another user, by default the superuser (root). It additionally creates an audit trail and a role-based access control system for system administrators. Installing software on a *nix-like system is typically done via a package manager, however this is not always necessary. Package management is a system level task that administrators typically like to be able to control and audit thus it is usually restricted to facilitate those needs.

You must log in to answer this question.

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