Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
  1. When you run an executable, sometimes the OS will deny your permission to. For example running make install with the prefix being a system path will need sudo, while with the prefix being a non-system path will not be asked for sudo. How does the OS decide that running an executable would require more privilege than a user has, even before the program does something?
  2. Sometimes, running a program will not be denied permission, but the program will be able to do more things if it is run with sudo. For example, when running du on some system directory, only with sudo it will be able to access some directory. Why does the OS not deny permission of running such a program, or friendly notify more privilege is preferred, before the program can run?
  3. Is it true that whenever sudo works, su will also work, and whenever su works, sudo will also work? or with su, a user can do more than with sudo? How does the OS decide when sudo works, and when su is needed?
share|improve this question

For the purposes you have described, the OS doesn't decide whether you need sudo to initially run the program. Instead, after the program starts running and then tries to do something that is not permitted by the current user (such as writing a file to /usr/bin to install a new command), the OS prevents the file access. The action to take on this condition is up to the program; make stops running but du will proceed to the next file/directory after printing a message.

The su and sudo commands are two different ways of running a program with root privileges. They may differ in minor details such as the contents of the environment when starting the new program, depending on options used. The OS does not need to decide when one or the other might work.

share|improve this answer
  1. Sometimes the "Permission denied" message is due to filesystem permissions denying you write access, for example. The executable/tool simply checks if it the filesystem grants you enough permissions to do what you're about to do and throws an error if it's denied by the filesystem. Other times, the tool itself will check your user ID before allowing you to continue using it.
  2. When you run a program with sudo you are running it under some other user's name. If that user is "able to do more things" than your user and the sudo configuration allows you to do these things on the other user's behalf then yes, sudo will allow you to do more things. This is not necessary, though. If you just tack sudo on at the beginning of the command line, you're actually sudoing as root, so typically you're able to do more things than a mere mortal.
  3. Most definitely not. To use sudo you need to supply your own user password and then you're allowed to do some things on the target user's behalf. To use su, you need the target user's password and if you have it, you become that target user as far as the system is concerned and can do anything that user can do.

See also

share|improve this answer
Thanks. Is " filesystem permissions denying you write access" = "access mode of the file has no execution bit set for the user, which can be set by chmod"? – Tim Jul 28 '14 at 20:36
@Tim Actually it = "access mode of file has no write bit set for the user". And yes, this can of course be remedied by chmod provided you're either the owner of the file or root. – Joseph R. Jul 28 '14 at 20:37
Does whether sudo is needed, completely and solely depend on whether the execution bit is not set for the user? See unix.stackexchange.com/q/147052/674 – Tim Jul 28 '14 at 20:39
@Tim Obviously you need the execute bit to be able to run the executable in the first place. – Joseph R. Jul 28 '14 at 20:41
@JosephR. Not obvious. chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./hello produces a nice "Hello, World!" output. – Doug O'Neal Jul 29 '14 at 11:15

su and sudo are privileged programs. su changes (after successful authentication) the real and effective user and group id to that of the user you su to. Thus, su is similar to login. Note that su can be used to change to any user, not just root. sudo also changes the real and effective user and group ids. Up to this point su and sudo are similar (but unrelated), beyond that they are very different.

With su, you need to know the target's password, and once you authenticated, you can do whatever you want as that user. The use of su can be restricted by setting SU_WHEEL_ONLY in /etc/login.defs. If it is set, only users in the group wheel may use su, otherwise it is not restricted. Apart from that, su is all or nothing.

sudo is completely different with respect to that. With sudo you can define quite complex policies in /etc/sudoers on what the sudoer (the user who calls sudo) is allowed to do. For instance, you can define policies where certain users may run only certain programs with certain privileges, while other users may run other programs with other privileges.

One of the striking features of sudo is that you can configure it such that a user has to authenticate himself with his own password (instead of that of the target). Thus, sudo has grown very popular amongst admins, for it allows to authorize users to do only defined privileged operations without dealing out the superuser password, plus you get some degree of accountability.

share|improve this answer

tl;dr Access is determined by the user who is running application, and sudo runs applications as different user.

Full version:

How does the OS know that a command needs sudo?

It doesn't know. UNIX manages permissions not on application level but on filesystem level: permissions are granted for users to access specific files. Applications then are run on behalf of user - each running process has user associated with it. That user is used to determine permissions for that application. Sudo works by running applications on behalf of other user (with permissions associated with that another user), namely root, the superuser.

As for your examples:

  1. If user has write access to particular directory, they can make install into that directory. Otherwise they may have root do it - by using sudo.

  2. If you cannot access files in a directory, du running for you cannot access it either. root can access virtually every file, so sudo du (du run on behalf of root) can access them too.

Is it true that whenever sudo works, su will also work, and whenever su works, sudo will also work?

Yes and no. Yes, if program is actually run, it should behave the same under both sudo and su. However, sudo provides allows for more fine-grained control of who may run what by set of rules stored in /etc/sudoers file. su is more simple - if you know target user's password, you can run programs on behalf of that user.

Last note: how application handles denial of access (wherher it aborts or ignores or warns user) is up to application.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.