What determines which Linux commands require root access? I understand the reasons why it is desirable that, say, apt-get should require root privilege; but what distinguishes these commands from the rest? Is it simply a matter of the ownership and execute permissions of the executable?

  • 2
    It's mainly a function of what file they touch and what functions they call. May 11, 2018 at 14:27
  • 11
    Some apps need access to files/dirs, owned by root. So, they just call open and get "permission denied". Some apps check getuid and stop working if they are not called by root. Some are physically owned by by root and only owner may execute them (see chmod). If you are asking if there is some "needs root" mark in app header -- the answer is no. There is no such thing afaik
    – user996142
    May 11, 2018 at 14:29
  • 2
    ps: several syscalls (like binding to well known port < 1024) may also need root access.
    – user996142
    May 11, 2018 at 14:34
  • apt-get doesn't require root at all. It's in the /usr/bin directory, see askubuntu.com/a/440791/169736
    – Braiam
    May 12, 2018 at 2:04
  • You might clairify what you mean by "require" here. Do you mean that the program won't execute unless you're root (or have sudo permissions), or that it needs to be root in order to do its job properly?
    – jamesqf
    May 12, 2018 at 5:05

3 Answers 3


It's mainly a matter of what the tool or program does. Keeping in mind that a non-superuser can only touch files that it owns or has access to, any tool that needs to be able to get its fingers into everything will require superuser access in order to do the thing which it does. A quick sample of Things that might require superuser access include, but are not limited to:

  • Opening a listening TCP socket on a port below 1024
  • Changing system configurations (e. g. anything in /etc)
  • Adding new globally-accessible libraries (/lib and /usr/lib) or binaries (/bin, /usr/bin)
  • Touching any files not owned by the user who is doing the touching which don't have a sufficiently permissive mode
  • Changing other users' files' ownership
  • Escelating process priorities (e. g. renice)
  • Starting or stopping most services
  • Kernel configuration (e. g. adjusting swappiness)
  • Adjusting filesystem quotas
  • Writing to "full" disks (most filesystems reserve some space for the root user)
  • Performing actions as other users
  • 4
    "Changing process priorities" non-root users can change niceties, to be more nice. The only thing they can't do is to be less nice.
    – Braiam
    May 12, 2018 at 2:05
  • 1
    I know this list is not complete, but I feel a very important task that only superusers can do is impersonating - or simply logging in as - other users.
    – phihag
    May 12, 2018 at 20:45
  • I've adjusted the bullet point about process priorities, and added "Performing actions as other users". Hopefully with sufficient time and comment, this list will become more comprehensive.
    – DopeGhoti
    May 14, 2018 at 15:27

In linux, the privileges of root were at one point divided into "capabilities", so you can get a full listing of root's special privileges by looking into that documentation: man 7 capabilities.

To answer your question, a command will require running as root when it needs one of these privileges, and its non-script executable does not have the relevant capability set in its file metadata (e.g. if a python script requires the capability, then the capability would need to be in the python interpreter specified in the shebang line).

Do note that some commands that need root access do not need something like sudo because they have the SUID bit set in their executable. This bit causes the executable to run as the owner (typically root) when executed by anyone that has execute access. An example is sudo itself as changing users is a privileged action it needs to do.

EDIT: I note from your question that you might have the idea that you can determine if a command will need root access before running it. That's not the case. A program may sometimes require root privileges and other times not, and this could be a decision made by the program because of data it's provided during runtime. Take for example, calling vim, just like that without arguments, and then through a series of keypresses and pasting, telling it to write something to a file it has no permission to write, or maybe executing another command that itself will require root privileges. Nothing about the command before executing could indicate that it would eventually require root access. That's something that can only be determined at the point it tries to do something that requires it.

Anyway, here are very few examples from the referenced manpage of the privileges of root:

  • Make arbitrary manipulations of process UIDs (setuid(2), setreuid(2), setresuid(2), setfsuid(2));
  • Bypass file read, write, and execute permission checks. (DAC is an abbreviation of "discretionary access control".)
  • Bypass permission checks for sending signals (see kill(2)). This includes use of the ioctl(2) KDSIGACCEPT operation.
  • Perform various network-related operations:
    • interface configuration;
    • administration of IP firewall, masquerading, and accounting;
    • modify routing tables;
  • Bind a socket to Internet domain privileged ports (port numbers less than 1024).
  • Load and unload kernel modules (see init_module(2) and delete_module(2));
  • Set system clock (settimeofday(2), stime(2), adjtimex(2)); set real-time (hardware) clock.
  • Perform a range of system administration operations including: quotactl(2), mount(2), umount(2), swapon(2), swapoff(2), sethostname(2), and setdomainname(2);
  • Use reboot(2) and kexec_load(2).
  • Use chroot(2).
  • Raise process nice value (nice(2), setpriority(2)) and change the nice value for arbitrary processes;

I think it is in accordance with the user's identity to verify permissions, not according to the order to divide the permissions. Files and users are privileged and commands should not be divided.

  • 3
    I don't mean to sound rude, and I understand english might not be your first language, but I don't understand this answer at all, like what it's even trying to say. "accordance" means "agreement" or "conformity"; I can't see how it can be used with "user's identity". What do you mean "order to divide the permissions"? "divide" means "to separate". Whose "order"? How are files "priviledged" when they're not something that can act to use any priviledge? I guess I can kinda understand "commands should not be divided" in the context of this question, but that's it. As it is, it seems unparseable.
    – JoL
    May 12, 2018 at 15:36
  • @JoL I think "the order" is a mistranslation and should be "the command", which allows for a different parse of that sentence. Somewhat awkwardly worded to use what's in this answer as much as possible: "I think it is in accordance with how the user's identity is used to verify permissions that permissions are not split according to the command. Privileges are about files and users, there should be no split for commands." This is still not too clear, but it makes a bit more sense to me than it does to you. I hope that my comment helps someone fully comprehend this answer and edit it into shape
    – hvd
    May 13, 2018 at 8:32

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.