53

I'm working with a support member for a product, and he insists that I need to be root to install a series of patches, and that sudo won't work; he doesn't provide a reason but seems very firm in his beliefs. Browsing Superuser I can't determine any possible reason for this being the case, and in confirmation, when I run:

sudo -l

I get:

...
User [MY USERNAME] may run the following commands on this host:
    (ALL) ALL

Getting access from the Linux/server team to actually be root is not an imediate process as I understand, so I'd prefer to install them myself.

Is there any practical reason whatsoever why sudo would behave differently than root for installing software on a server?

Hastur
  • 18,764
  • 9
  • 52
  • 95
Ranger
  • 703
  • 2
  • 7
  • 12
  • 2
    I think you should throw it back on him. As others have shown, there are a myriad of ways to gain root using sudo and if he cannot provide you with a concrete reason as to why sudo is insufficient, then he has no leg to stand on. – Garrett Jun 20 '14 at 22:27
  • 1
    Environment and subcommands come to mind. I think Hastur did a good job with environment, and Jayen did a goo job with subcommands, piping and redirection. – jww Jun 22 '14 at 02:14
  • 2
    Garrett has a good point, but before I got into a potential pissing contest, I would ask the support member: have you tried it both ways and has it failed one of those ways? He may have been down the failure road with `sudo` and the scripts as the scripts are currently written. If that's the case, then sds' answer might be most helpful to you: `sudo su -`. – jww Jun 22 '14 at 02:16

5 Answers5

40

It strongly depends on how you call your program with sudo or su.
E.g. on the system on which I am in this moment:

                  .bashrc                        
    COMMAND        $HOME   $USER  Env.  $PATH
 1. sudo -i        (root)   root  root  [1]
 2. sudo -s        (USER)   root  USER  /home/${USER}/bin:[1]
 3. sudo /bin/bash (USER)   root  USER  /home/${USER}/bin:[1]  
 4. sudo su        (root)   root  USER  [1]:/usr/games:/usr/local/games  
 5. sudo su -      (root)   root  root  [1]

Where [1]=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Env=Environment variables are reset for 1 and 5, taken from $USER in 2,3,4.

So a script, or a program that is launched with a different option can see different $PATH, $HOME, its shell can read different .bashrc,.profile and Environment variables. It reads the file related with the $HOME. Each user can modify his environment in a different way (variables, $PATH, .bashrc, .profile, .bash_profile, alias...). In particular a user can have a different order of the directories in his $PATH and, as a consequence, a script can execute a command e.g. in /home/$USER/bin instead then the one in the path expected from root.

You can run the program under sudo -i as you were logged as root with su -, but you can have different behaviour if you run it with sudo MyCommand or with su -c MyCommand.

From man su:

In the description part:
The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the superuser
...
In the options part:
-, -l, --login
Provide an environment similar to what the user would expect had the user logged in directly.

From man sudo

-i, --login
Run the shell specified by the target user's password database entry as a login shell. This means that login-specific resource files such as .profile or .login will be read by the shell. If a command is specified, it is passed to the shell for execution via the shell's -c option. If no command is specified, an interactive shell is executed. sudo attempts to change to that user's home directory before running the shell. The command is run with an environment similar to the one a user would receive at log in. The Command Environment section in the sudoers(5) manual documents how the -i option affects the environment in which a command is run when the sudoers policy is in use.

Hastur
  • 18,764
  • 9
  • 52
  • 95
  • Great answer. I'm still a novice at Linux, but is another difference that what you can do using `sudo` can be limited by permissions in the sudoers file vs. doing things as root doesn't have those limitations? The last block quote maybe implies that, but if I understand correctly, that seems like another substantive difference beyond just the environment (or maybe because of the environment?). – fixer1234 Sep 07 '16 at 15:09
25

If you have full sudo access, you can become root using sudo su -, so the security point is moot.

Indeed, there is a way to discern the difference between a program ran as root and a program ran under sudo - using getuid vs geteuid - but this is a contrived trick. Why would a patch system do that?

sds
  • 1,960
  • 2
  • 22
  • 33
  • 5
    Speaking of `su -`, he might want to use `sudo -i` so that he has the same environment as when logging in directly. – Cristian Ciupitu Jun 20 '14 at 21:30
  • 2
    If you run with e.g. `sudo myscript` you will keep $PATH and environment variables from the shell in which you are. If you run with `sudo -i myscript` you run as if you login as root. See the answer with our [_zoo of calls :-) _](http://superuser.com/a/771523/257269) – Hastur Jun 20 '14 at 23:22
  • This distinction can in fact be discerned by comparing the result of `geteuid()` with the result of `getuid()`. If you happen on a program not working correctly under sudo, this is almost certainly the cause. – Charles Duffy Jun 21 '14 at 14:51
  • 1
    I think it's important to point out that environmental variables may not be setup the same under `sudo` as logging in as root – secretformula Jun 21 '14 at 15:03
  • 1
    @dmanexe: sudo doesn't stand for superuser do, it's "switch user do". su and sudo can be used to switch to any users rather than just the superuser. Also there is nothing pseudo about sudo, you really get the actual root when running sudo not some faked anything. Note that the magic of sudo really comes from setuid permission bit. – Lie Ryan Jun 22 '14 at 01:47
  • 2
    sds, @CharlesDuffy: The idea that sudo and su cause `geteuid()` and `getuid()` to be different from one another *is a myth.* su and sudo change both the real and effective user IDs to those of the target user before running the specified command or shell, except in the very unusual situation that you've explicitly configured them to behave otherwise. You can verify this (for sudo) by running `sudo id -u` and `sudo id -ru` (both show 0), reading [sudo(8)](http://www.sudo.ws/sudo/man/1.8.10/sudo.man.html) (under *COMMAND EXECUTION*), or [writing a test program](http://paste.ubuntu.com/8383029/). –  Sep 19 '14 at 22:17
  • @EliahKagan, I thought I recalled a firsthand contrary observation -- looking up the associated bug and patch, however, it turns out to be resulted to the use of the setuid bit alone, rather that sudo. – Charles Duffy Sep 20 '14 at 01:50
  • @EliahKagan, (...the bug in question relating to a case in which it was necessary to call `setuid(geteuid())` for systemd's authentication of processes communicating with it over IPC to function properly). – Charles Duffy Sep 20 '14 at 01:58
7

There are a few differences if you are getting a root shell, as pointed out by @Hastur.

If you are not getting a root shell, then there are more differences. The support member may have experience trying to do things like sudo patch -p0 < /root/patch.file where patch is run as root, but < (piping from a file) is not.

Jayen
  • 512
  • 5
  • 18
  • 1
    Right: the practical point of view often offers hints that are harder to spot only from the man pages. To overcame similar situation you are forced do _more gym_ [:-)] e.g. write something like `sudo /bin/bash -c "./patch -p0 < /root/patch"`. Even more delicate is the case when you use redirection to create a file `>`. In the first way you will create a file that belongs to the user only if you have enough right to write in the final directory. In the latter way you will create a file _owned by root_... the dark side of Unix ;-) – Hastur Jun 21 '14 at 05:54
1

I beleive when using sudo access, a log file is created, however when running directly through root access there is not.

Ashley Redman BSc
  • 73
  • 5
0

It depends how fine grained you want the root access to be. If you have several users that perform different tasks on a system then sudo would be more ideal. One example I use frequently is the need to restart an application or database. Security is always best done least privileged. I use groups and only allow those groups to perform explicit actions. A good book that describes this process is "Sudo Mastery: User Access Control for Real People". Actually it is a good book about sudo in general...

meredithkm
  • 1
  • 2