May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Introduction to Sudo (superuser do)

Softpanorama main  >  Access Control in Operating Systems > sudo


Access Control

Recommended Links The su Command Reference Wheel Group
Sudo on AIX Sudo for HPUX Solaris RBAC Group administration SUID/SGID attributes The umask
Root Account Root Security Admin Horror Stories History Humor Etc


One problem with Unix security is not that root is all-powerful, but that regular accounts are not powerful enough to be useful for many common tasks.  One way to solve this Unix problem was sudo, the utility that can grant to non-root account root access on "per-command" basis.  Essentially sudo is a rudimentarily implementation of RBAC (see, for example Solaris RBAC) in a completely portable Unix-flavor independent way.  All problem related to proper structuring of roles are present in sudo, as soon as it is used for anything else then access of root account by non-root but privileged (typically members of Wheel Group) users.

Sudo (superuser do) is an extension of the classic Unix command su (introduced in BSD). It allows a system administrator to work using his own account and switch to root or other user identity available on the system only for commands that need it. In most cases it is used to as "one command switch to root". It also protect system administrators from horrible mistakes that can happen when you work as root all the time. In case you are tired you can do a lot of damage with just one "subconscious" mistake. For example, if you accidentally type rm /etc* instead of rm etc*. See Admin Horror Stories for a overview of typical "horrors" of this time. In other words working in your own account all the time and using sudo prefix when you need to execute commands as root is much safer way of working for sysadmins. Here the value of sudo is undisputable. 

In addition sudo provides logging of commands which you submitted. That also has value when, say, two people administer the same server. Otherwise  to understand what was done by your partner is not easy, as sysadmin typically are in a hurry and seldom completely document their actions. Sometimes people lie and try to hide their mistakes. Here you have some chances to recreate the set of actions of your partner.

Sudo is useful on all version and flavors of Unix, with possible exception of Solaris 10 were native OS mechanisms (RBAC) are superior. For a brief history of Sudo see history section

Sudo is integrated in OpenBSD and Ubuntu and pre-installed on enterprise linux distributions (RHEL and Suse). It is not installed on AIX and HP-UX but it is available in "vendor-precompiled", "vendor-unsupported" form. See

The great advantage of sudo is that it can (and should) be deployed on all Unix systems under administration (it's pretty simple to deploy if via SSH).  This universal availability is a huge advantage over other similar packages.

Suse has a turbulent history with many vulnerabilities fixed at different periods of time. While sudo provide an elegant way to provide to users temporary root capabilities without communicating to the user root password, there is no easy way to prevent a user from gaining a root shell if that user is allowed to run commands with shell escape via sudo. Many programs (such as editors) allow the user to run commands via shell escapes, thus avoiding sudo's checks. Some Unix utilities such as find  and xarg, allow execution or arbitrary commands. However, on most systems it is possible to prevent shell escapes with sudo's noexec functionality.

The current version as of April 2013 is 1.8.6p8, but most linux distros provide only much older (but adequate) version 1.7.6p2 (called Maintenance release on sudo site).  It's now pretty complex product which is the major deficiency. Security vulnerabilities are periodically discovered and for open source program of such complexity its presence in the system is essentially a free backdoor to root as it is reasonable to assume that for any version there is at lease one unknown zero-day exploit.  There is a great need for simpler and more secure "sudo-light"...

In some organizations and flavors on Linux (such as Ubuntu) root account has password disabled and the only way to access root is via sudo.  This concept is called Rootsudo in Ubuntu

Minimal usage of sudo and possible alternatives

Minimal usage of sudo involves execution of a command as root by prefixing it with the name of program (sudo). For example:

sudo passwd root

The simplest alternative to this functionality is a copy of shell renamed as sudo, set the SUID  attribute  and make it owned by wheel group with the execute permission for group enabled. For example:

cp /usr/bin/bash /root/bin/sudo
chown root:wheel /root/bin /root/bin/sudo
chmod 750 /root/bin
chmod 4710 /root/bin/sudo

In this case you get basic passwordless sudo functionality for wheel group members using standard Unix facilities which is important for "strange" flavors of Unix such as HP-UX where sudo port behaves somewhat strange (AIX, another "strange" Unix has a usable sudo port).

Another rarely used but viable alternative to sudo is ssh. You can try to use ssh with a public key, which provides passwordless login like:

alias sdo='ssh root@localhost '
sdo your_command 

To do this, you must create a public/private key pair for the user who should be allowed to ssh into the root account and then put the public key into root's authorized_keys file. You may restrict this key to execute only by writing

in front of the public key in root's authorized_keys file. You also have to allow root login in the sshd_config file:
PermitRootLogin yes

Disadvantage (which you may consider to be an advantage as well) is that this passwordless connection to the local host will reinitializes your environment each time you use the command .

Main advantages

Sudo popularity emerged not accidentally. It has several advantages, representing, in essence, a minimal implementation of RBAC for Unix. Among them:

Main components

Conceptually sudo is a really simple package that unfortunately grow too complex with time. It consist of just three utilities (sudo, visudo and sudoreplay) and a single configuration file /etc/sudoers. I would recommend to pay a special attention to  sudoreplay as it provides the functionality of automatic logging of your commands and then converting them into a script the can be replayed on other servers.

  1. sudo(8) command: setuid root wrapper that users invoke to execute commands as root (or other privileged account).
  2. /etc/sudoers. This is a key configuration file which can also be located in /etc/sudo or /usr/local/etc directory. It is sudo's roles definition file specifying who may run what commands as which user. It is fully documented in sudoers(5). See also a good into in Gentoo Sudo(ers) Guide
  3. visudo(8) command allows administrators to edit the sudoers file without risking locking themselves out of the system.
  4. sudoreplay  plays back or lists the session logs created by sudo. When replaying, sudoreplay  can play the session back in real-time, or the playback speed may be adjusted (faster or slower) based on the command line options.
    List sessions run by user millert:
     sudoreplay -l user millert

    List sessions run by user bob with a command containing the string vi:

     sudoreplay -l user bob command vi

    List sessions run by user jeff that match a regular expression:

     sudoreplay -l user jeff command '/bin/[a-z]*sh'

    List sessions run by jeff or bob on the console:

     sudoreplay -l ( user jeff or user bob ) tty console

Sudo is distributed under a BSD-style license and currently maintained by Todd Miller. The current homepage is

Problem of escape to shell

Like in any complex security program the security record of sudo itself is questionable and there were several exploitable vulnerabilities in different versions; also like with many other open source programs, it looks like there is not much development discipline: capability of the program grows non-stop without much architectural vision, evaluation of the return on the investment and general security of code. As a result the current version is far from being a simple elegant tool it used to be. It has just too many options, keys etc. Some recent enhancements probably were not necessary and mainly increased the complexity of the codebase. Contrary to common perception sudo does not really provide for a role structuring facility similar to RBAC: any assignment of a capability to execute a complex command capable of executing other commands (or invoke shell) without envelope that checks and fixes arguments (for example find or ex) essentially means conversion of this "restricted" account into backdoor for the root, if this command is executed as root. Some of those escapes to shell can be blocked via Sudo noexec  option.

Sudo vs ACL: overlaying account based permissions using sudo

Sometimes sudo is used to accomplish tasks related to access to specific command and files which also can be  accomplished via ACLs. For example ACLs is preferable for granting read or write access to specific set of files for particular user. But sudo can restrict command to specific arguments, which ACLs can't do.

In both case you essentially create additional hidden infrastructure on top of regular Unix permissions. With sudo this infrastructure is even less visible then in case of ACLs.  As such those capabilities should be deployed only as "the last option" when Unix groups facilities can't help.

Still, if we are talking about fixed, static commands such an approach is permissible. But granting a "read-only" and "re-write" assess to some root owned files by granting usage of explicit cat (or cp in case of re-write access) commands for selected files is a bad solution. This problem should be solved using either standard Unix groups or, if standard Unix groups are insufficient with ACLs.

Also you need to remember that even static commands can represent a security hole if they can escape to shell and usage of noexec option is a much in all such cases.  But even this is dangerous and this protection can be broken and the privilege can be abused.

Sudo is great when cases of usage are simple and limited to few users. As soon as sudoer file become complex this complexity sooner or later  can byte you unless it is structures as a repetition of the same relatively simple grants for different users. 

One needs clearly understand that granting a user the right to run any command with shell escapes like "vi" or "find" as root is equivalent to granting root access. Actually granting to users, who are not system administroars the ability to execute any command with root privileges without strict control of arguments is dangerous and prome to abuse.

One needs clearly understand that granting a user the right to run commands with shell escapes like "vi" or "find" as root is equivalent to granting root access.

Restricting execution capabilities of regular user account is mostly useless: the problem is not excessive capabilities of regular account, but the lack of thereof. But it does make sense for applications. Applications are a different beast and here sudo can and should be useful if you cannot use restricted shell, chroot or similar things:

Defaults syslog_goodpri=alert

# Cmnd alias specification
Cmnd_Alias DNS = /var/dss/vinamed.boot, /var/dss/vidb.root, /usr/bin/kill - HUP *
Cmnd_Alias MAILCMDS = /usr/local/bin/aliases, /usr/local/bin/qlist, /usr/local/bin/qlist2, /usr/local/bin/qreport, /usr/local/bin/qreport2, /usr/local/bin/qdelete, /usr/local/bin/qdelete2, /etc/rc3.d/S88sendmail
Cmnd_Alias MONITORCMDS = /etc/rc3.d/S88sendmail, /usr/bin/su - pmx4 *


Providing wheel group access to root via sudo

As I mentioned before the first really elegant sudoer configuration is as simple as:

%wheel ALL = (ALL) ALL 

where the wheel group consist of all administrators. In this case anytime sysadmins need to execute command as root he/she just prefix it with sudo. This is actually an imitation of the BSD wheel group functionality and what is really nice that it can be accomplished on any flavor of Unix although a PAM-based implementation is better on those systems were it is available (Solaris, Linux).

In Solaris this is useful only for compatibility in multi-Unix enterprise environment and the group used probably should be not the wheel group but sysadmin group. The latter has additional capabilities not dissimilar to BSD wheel group (in Solaris this is the ability to change attributes of files via Admintool).

%sysadmin ALL = (ALL) ALL
Similar trick is possible for operator group
%operator ALL = NOPASSWD: /usr/bin/su operator

Actually this part of sudo functionality can be easily implemented without sudo using additional copy of /bin/sh (sudo can used as the name of the copy) with permissions 4550 and owned by root:wheel or in Solaris root:sysadmin. It provides probably 80% of sudo usefulness in preventing root role "overstaying" for administrators with access to the root role (assuming that all of them are members of the group wheel or sysadmin). This solution lacks logging and other nice features provided by sudo, but it does avoid sudo overcomplexity. In certain cases when adding software to the server is prohibited, it can serve as a "poor man sudo" and it might help to avoid risks connected with root role "overstaying" as well as potential security holes inherent in the current version of sudo with all its complexity.

Here are some additional examples from the sudo manual:

Since the sudoers file is parsed in a single pass, order is important. In general, you should structure sudoers such that the Host_Alias, User_Alias, and Cmnd_Alias specifications come first, followed by any Default_Entry lines, and finally the Runas_Alias and user specifications. The basic rule of thumb is you cannot reference an Alias that has not already been defined.

Below are example sudoers entries. Admittedly, some of these are a bit contrived. First, we define our aliases:

 User_Alias     FULLTIMERS = millert, mikef, dowdy
 User_Alias     PARTTIMERS = bostley, jwfox, crawl
 User_Alias     WEBMASTERS = will, wendy, wim
 Runas_Alias    OP = root, operator
 Runas_Alias    DB = oracle, sybase
 Host_Alias     SPARC = bigtime, eclipse, moet, anchor :\
                SGI = grolsch, dandelion, black :\
                ALPHA = widget, thalamus, foobar :\
                HPPA = boa, nag, python
 Host_Alias     CUNETS =
 Host_Alias     CSNETS =,,
 Host_Alias     SERVERS = master, mail, www, ns
 Host_Alias     CDROM = orion, perseus, hercules
 Cmnd_Alias     DUMPS = /usr/bin/mt, /usr/sbin/dump, /usr/sbin/rdump,\
                        /usr/sbin/restore, /usr/sbin/rrestore
 Cmnd_Alias     KILL = /usr/bin/kill
 Cmnd_Alias     PRINTING = /usr/sbin/lpc, /usr/bin/lprm
 Cmnd_Alias     SHUTDOWN = /usr/sbin/shutdown
 Cmnd_Alias     HALT = /usr/sbin/halt
 Cmnd_Alias     REBOOT = /usr/sbin/reboot
 Cmnd_Alias     SHELLS = /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh, \
                         /usr/local/bin/tcsh, /usr/bin/rsh, \
 Cmnd_Alias     SU = /usr/bin/su
 Cmnd_Alias     PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less

Here we override some of the compiled in default values. We want sudo to log via syslog(3) using the auth facility in all cases. We don't want to subject the full time staff to the sudo lecture, user millert need not give a password, and we don't want to reset the LOGNAME, USER or USERNAME environment variables when running commands as root. Additionally, on the machines in the SERVERS Host_Alias, we keep an additional local log file and make sure we log the year in each log line since the log entries will be kept around for several years. Lastly, we disable shell escapes for the commands in the PAGERS Cmnd_Alias (/usr/bin/more, /usr/bin/pg and /usr/bin/less).

 Defaults               syslog=auth
 Defaults>root          !set_logname
 Defaults:FULLTIMERS    !lecture
 Defaults:millert       !authenticate
 Defaults@SERVERS       log_year, logfile=/var/log/sudo.log
 Defaults!PAGERS        noexec

The User specification is the part that actually determines who may run what.

 root           ALL = (ALL) ALL
 %wheel         ALL = (ALL) ALL

We let root and any user in group wheel run any command on any host as any user.


Full time sysadmins (millert, mikef, and dowdy) may run any command on any host without authenticating themselves.


Part time sysadmins (bostley, jwfox, and crawl) may run any command on any host but they must authenticate themselves first (since the entry lacks the NOPASSWD tag).

 jack           CSNETS = ALL

The user jack may run any command on the machines in the CSNETS alias (the networks,, and Of those networks, only has an explicit netmask (in CIDR notation) indicating it is a class C network. For the other networks in CSNETS, the local machine's netmask will be used during matching.

 lisa           CUNETS = ALL

The user lisa may run any command on any host in the CUNETS alias (the class B network

                sudoedit /etc/printcap, /usr/oper/bin/

The operator user may run commands limited to simple maintenance. Here, those are commands related to backups, killing processes, the printing system, shutting down the system, and any commands in the directory /usr/oper/bin.

 joe            ALL = /usr/bin/su operator

The user joe may only su(1) to operator.

 pete           HPPA = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root

The user pete is allowed to change anyone's password except for root on the HPPA machines. Note that this assumes passwd(1) does not take multiple usernames on the command line.

 bob            SPARC = (OP) ALL : SGI = (OP) ALL

The user bob may run anything on the SPARC and SGI machines as any user listed in the OP Runas_Alias (root and operator).

 jim            +biglab = ALL

The user jim may run any command on machines in the biglab netgroup. sudo knows that ``biglab'' is a netgroup due to the '+' prefix.

 +secretaries   ALL = PRINTING, /usr/bin/adduser, /usr/bin/rmuser

Users in the secretaries netgroup need to help manage the printers as well as add and remove users, so they are allowed to run those commands on all machines.

 fred           ALL = (DB) NOPASSWD: ALL

The user fred can run commands as any user in the DB Runas_Alias (oracle or sybase) without giving a password.

 john           ALPHA = /usr/bin/su [!-]*, !/usr/bin/su *root*

On the ALPHA machines, user john may su to anyone except root but he is not allowed to give su(1) any flags.

 jen            ALL, !SERVERS = ALL

The user jen may run any command on any machine except for those in the SERVERS Host_Alias (master, mail, www and ns).

 jill           SERVERS = /usr/bin/, !SU, !SHELLS

For any machine in the SERVERS Host_Alias, jill may run any commands in the directory /usr/bin except for those commands belonging to the SU and SHELLS Cmnd_Aliases.

 steve          CSNETS = (operator) /usr/local/op_commands/

The user steve may run any command in the directory /usr/local/op_commands/ but only as user operator.

 matt           valkyrie = KILL

On his personal workstation, valkyrie, matt needs to be able to kill hung processes.

 WEBMASTERS     www = (www) ALL, (root) /usr/bin/su www

On the host www, any user in the WEBMASTERS User_Alias (will, wendy, and wim), may run any command as user www (which owns the web pages) or simply su(1) to www.

 ALL            CDROM = NOPASSWD: /sbin/umount /CDROM,\
                /sbin/mount -o nosuid\,nodev /dev/cd0a /CDROM

Any user may mount or unmount a CD-ROM on the machines in the CDROM Host_Alias (orion, perseus, hercules) without entering a password. This is a bit tedious for users to type, so it is a prime candidate for encapsulating in a shell script.

Some points for the large enterprise environment the advantages of deploying SUDO (based on article: Sudo at a VERY LARGE site) are as following:

To get a good idea of what sudo can do, you really need to take a look at a sample sudoers file.

See also





Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019