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.
Conclusion
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.
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.jack
callsapt-get install vim
, it gets back: "no need to install vim; your friendbill
has already installed it in/home/bill/.local/
".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 thatbill
andjack
both have their own separate binaries (with the libs that were missing on the system)