Sudo vs root; any actual differences?

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?

Solution 1:

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.

Solution 2:

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?

Solution 3:

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.

Solution 4:

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