- When you run an executable, sometimes the OS will deny your
permission to. For example running
make installwith 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?
- 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
duon some system directory, only with
sudoit 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?
- Is it true that whenever
suwill also work, and whenever
sudowill also work? or with
su, a user can do more than with
sudo? How does the OS decide when
sudoworks, and when
- 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.
- When you run a program with
sudoyou are running it under some other user's name. If that user is "able to do more things" than your user and the
sudoconfiguration allows you to do these things on the other user's behalf then yes,
sudowill allow you to do more things. This is not necessary, though. If you just tack
sudoon at the beginning of the command line, you're actually
root, so typically you're able to do more things than a mere mortal.
- Most definitely not. To use
sudoyou 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.
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.
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.
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
sudo are similar (but unrelated), beyond that they are very different.
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
/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.
tl;dr Access is determined by the user who is running application, and
sudo runs applications as different user.
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:
If user has write access to particular directory, they can
make installinto that directory. Otherwise they may have
rootdo it - by using
If you cannot access files in a directory,
durunning for you cannot access it either.
rootcan access virtually every file, so
durun 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 provides allows for more fine-grained control of who may run what by set of rules stored in
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.
No one has a ✓ yet, so I put together an answer that has everything I could think of.
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?
No it is not done when an executable is started. It is done when the executable tries to do something.
The Os will check file-system permissions, and capabilities (these are not covered by file-system permissions, and include reduce nice level, mknode, some low-level network stuff, kill other's processes, reboot, set time etc.). If you do not have the permissions then you can not do it. Root has full set of capabilities, including CAP_DAC_OVERRIDE (ignore file permission).
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?
The OS can not know what the program will do. So it is up to the program to check permissions before it starts, and to decide what to do. It does not have to do this though.
Note: on android there is a manifest, in this the application declares what privileges it may use. The OS will kill any application that tries to use a privilege that it does not declare, and the OS does not always guarantee that a privilege can be honoured. e.g. network access may not be available.
2 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?
su do roughly the samething. Some differences is environment variable handling and other such security issue avoidance. However they are both tools to allow you to become another user, and both have a default user of root.
su was the original tool, it requires you to enter the password of the user/group that you are changing to.
sudo is newer and requires, by default, for you to enter your own password, but can be configured to accept the password of the user/group that you are switching to, or no password at all. It also allows a lot of configuration, of what commands it will work with, for who, and how it will authenticate with this program for this user on this machine. There is also
sudoedit this is part of
sudo and can be used to allow editing as a different user and avoid the security issue of sub-shelling out of an editor (calling exec from the editor to run an arbitrary process with escalated privileges).