Sudo Privileges
Users with root or administrator access rights can perform certain tasks that regular users can not. The sudo (superuser do) command is used on Unix and Linux systems to give root or administrator access rights to regular users.
This article applies to: Managed Servers
Caution: Sudo is a powerful privilege. (That's why it's limited to select users.) Users granted sudo privileges should be sure they understand the best practices for its use.
Requesting Sudo Access
Sudo privilege is given to individual accounts on a “need to” basis. Area Managers may submit requests for sudo privileges for user accounts.
- If you are setting up a new account, request sudo access on the Unix Account Request Form.
- If you want to add sudo access to an existing account, the manager with administrative authority over the server should submit a request in email to systems-support@cornell.edu. Explain which user needs sudo access and why.
Best Practices Guidelines for Sudo
- Do not use sudo to gain access to the root or “human” identity accounts or to access other people's files. (This includes using commands such as sudo su.) Application user ids (for example, user ids not affiliated with a specific person and for which there is no usable password) are exempt from this rule.
- It is good practice to disable or tightly restrict direct login to non-human accounts (for example, Oracle). It is appropriate to use sudo su to work in non-human accounts.
- Activities invoked by sudo are logged. The log file is important when it is necessary to troubleshoot problems or fix errors. When using sudo, do not attempt to prevent logging. (For example, by spawning a separate command shell and executing commands in that shell.)
- In some specific cases, it may be necessary to spawn a new command shell. For these cases, use the sudosh utility to create a session-logged shell. When the session is complete, e-mail the id of the session and an explanation of the activity contained in it to systems-support@cornell.edu. Please note that sudosh is not for casual use. The tools to audit sudosh sessions work in real-time so keep your sudosh sessions brief and specific. Examples of appropriate use of sudosh:
- Working within a directory that is only readable by root (for example, /var/spool/mqueue).
- Running a software installer that requires root privileges and has been proven to fail when run using sudo.
- Editing a config file that requires root privileges to write.
- Leaving a sudosh session idle for an extended period of time.
- Running a shell under sudosh purely to avoid needing to retype “sudo.”
Comments?
To share feedback about this page or request support, log in with your NetID