I Have The Power! – su vs. sudo: Core Concepts of Being a Superuser

For the new Linux user, that is quite a bit of weird looking garbage in the title, right?  The concept of the “Super User” is one that is often mis informed, or very much abused.  Too often users will use the super user account for things that do not even require it, or use it exclusively as their regular account.  This ia very bad way to go about things, and you’ll soon find out why.  A good misnomer:  I am *not* an expert, but pride in learning the best methods and concepts of any particular concept.  Read on for more.

su

‘su’ will switch to another user account entirely, and is one of the most powerful interactions you can have with the system, apart from actually logging into your system directly as root.  su will allow you to log in as another user, on the fly, and perform actions as that other user.  By default, ‘su’ will log you into a shell as root, so it is highly important to use the syntax ‘su <username> ‘ if you wish to log in as another normal user.  The advantage of su in an existing login session, is the ability to preserve environment variables from the original shell.  You will be required to enter a password if you are not already the root user.  

When logged in as a different user, every action you now take mimics as if you were logged in as that new user.  This means, changing to the root user via ‘su root’ or ‘su’ will allow every action going forward to be executed as that user instead.  This particular use with root, is discouraged, unless you know exactly what you are doing, and do so only for things that need explicit root access.  Typically it is not a good idea to run your regular system as root exclusively.   On a particular note, running ‘su -‘ will replace your environment with that of the root users, making everything you do indistinguishable from logging in as that root user. 

sudo

‘sudo’ is quite another kind of beast.  ‘sudo’ will run a single command with root privileges.  Think of it as “temporary  elevated access,” in the same vein as the highly annoying UAC prompts of Windows 7 and above.  When you run a command as sudo, the system will parse your assigned privileges in the ‘visudo’ configuration and apply appropriate access temporarily.  You will be prompted for your password, and typically, unless not configured, will log your actions.  This accountability is a very strong point in a multi-user environment.  For a brief amount of time, you will have a window of which running ‘sudo’ will not ask for the password again.  Run over your allotted time (default is around 15 minutes), then you must enter your password again.  You may change this time in visudo with ‘Defaults:user_name timestamp_timeout=10’, but I highly discourage it.  This is the same reason  you lock your PC when you get up from it. 

Now sudo is kind of a debatable thing for most.  You will get high level users with varying opinions on this.  The concept of giving the user the proper access to groups is a much more preferred way of maintaining some sort of ACL, aside from other concepts.  Sure, you could duplicate root access in visudo in the appropriate spot (‘user   ALL=(ALL:ALL) ALL), but the traditional act of adding the user to the ‘wheel’ group and specifying that in visudo is more appropriate.   Then adding any user to that group will apply the same permissions, making management a bit easier.  But, if you wish to remain granular in what you grant a user, you may continue to specify access per user in the visudo file.  Of note though is running ‘su -c’ will essentially give you some similar use of using ‘sudo’. passing a single command through. 

In the details: sudo vs su

Here is what matters most, su vs. sudo.  sudo will execute commands as the target user, changeable by adding a ‘-u’ to sudo, but still tags the username to assign blame later 🙂  ‘sudo’ is configurable, and can limit user’s access in a variety of ways, and holds that user accountable, as well as assign a user to a specific group and appropriate access in ‘visudo’.    When you use ‘su’, you now have total control of the system, which in many cases is a very bad thing, especially for a new user.  I myself, even as an Arch Linux user, never use su, only in the rarest cases. Because sudo takes the users password instead of the root users, you can isolate users in that sense, and keep them away from things they should not be near. 

Where you can run into trouble is certain “tricks,” such as a user executing into something like the vi editor with ‘sudo vi ‘ and being able to “shell out” of vi, gaining the same ability as ‘sudo -s’ (which runs the shell specified by the SHELL environment variable if it is set or the shell as specified in the password database).   ‘sudo -s' will not change your environment variables, especially $HOME, which will stay HOME=/home/USER.  The difference between ‘sudo bash’ and ‘sudo -s’ is ‘sudo -s’ looks in trusted locations to determine which shell to execute.  ‘sudo bash’ cause sudo to run the first bash program in the $PATH, which may not be the shell you intended to run.  This all comes down to spoofabilty, and controlling specifically how shells are handled from a security standpoint.  However, precedence is on the SHELL variable over /etc/password, so there are still some pitfalls. 

8-15-2013 09-50-00

A much better look at the differences

Recently I have read that ‘sudo -i’ is  a safer alternative which gives you a root login shell, but resets many of the key environment variables.  ‘sudo -i’ only looks at /etc/passwd and replaces the PATH.  This amounts to far better security than previous options.  The bottom line is sudo -i is the proper command to run when you want a root shell that is untainted by the user’s environment.  Both ‘sudo -i’ and ‘sudo -s’ aim to get you a shell running as root.  The differences lie in the environment variables in use.  ‘-i’ more closely simulates logging in as that specific user, vs ‘-s’ giving you just the users shell.  Think of ‘-i’ as interactive.

Differences with 'sudo -i'

Differences with ‘sudo -i’ Click the picture for large format.

Note: See the man page of sudo  and su for more.

gksu

For those who rely on GUI implementations of all their programs, there is ‘gksu’ as well.  The command has a few tricks, of note is the ability to preserve your current desktop settings, so graphical programs won’t look out-of-place when you launch them as another user.  When launching a graphical application, gksu is widely advised over launching the GUI application with sudo explicitly. 

Conclusions

The decision of using ‘su’ vs ‘sudo’ or the entire lack of, is something that has a wide range of opinions.  Since I am not a Linux sysadmin at the moment, take my advice with a grain of salt, but believe me when I say I care very much about this issue, and am always open to correction.  In fact, some distributions don’t even give you the option of root access from the get go, and require sudo for all elevated actions.  Ubuntu is a prime example of this.  If you are not sure if you need root access, don’t do it, and consult someone who knows, or seek the appropriate documentation.

Using visudo to keep user accountable is  a much more palatable method of control, aside from other security methods.  Running everything as root is a dangerous dance, and before you know it, a new user will find themselves in hot water when they run a command they should not have.  Some applications by default won’t even run on root access (I have seen this with Chromium).  Auditing is a huge benefit of visudo, while to some degree (with auth.log).  Visudo keeps users away from the root password most importantly, as instill caution about what they are about to do.  At the same time, you want to teach them not to use sudo when they don’t need to.  This happens all too much it seems.  While you can duplicate sudo with the ‘-c’ option, as stated earlier, you still must know the root user password.  In the end, visudo, with the right options is a far better methodology for the general user.  =

While su is the more “traditional” method that has been around for ages, and it is highly debatable among Unix/Linux users as to what is the better option.  The main thing is accountability and password management.  You do not want every user knowing or using the root user account.  Even on a single user machine at my home, I do not rely on su, even ‘su -c’, to run a single command through.   The amount of options in su and sudo are pretty extensive, so be sure to check out their respective man pages. 

_professor

Also see:

Some more info:

Advertisements

About professorkaos64

www.libregeek.org

Posted on 20130816, in Core Concepts, Featured articles and tagged , , , , , . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s