- About Us
- Computer Forum
Privileged Access Policy
Privileged Access (i.e., root or root equivalents) for machines managed by CSD-CF are bestowed to those who need it via the sudo command (sudo is short for "SUperuser DO"). To use it, simply prefix the command you want to run as root with "sudo". For example:
sudo will ask you to authenticate yourself by typing in your password. sudo remembers your password for five minutes after the last sudo command you ran, so that you don't have to continually enter your password.
Why we use sudo instead of giving out the root password:
- Root is all powerful.
- The root user can hide all of their actions.
- The root password gives you access to any command on a system.
In Unix and Unix-like systems, system administration privileges are all or nothing. A user either has root access or not, and root access implies complete control of a machine. If the machine in question is used by more than one person, or root has access to other systems or user files, it is more acceptable to give some users partial root privileges.
sudo logs every command run via sudo. Having a record of what's being done with sudo helps us diagnose problems with individual systems/processes and general confiugration issues, as well as helping us identify needed improvements.
Via its config file, sudo can give a user root access for particular set of commands. This also avoids the "all or nothing" effect, alllowing us to give individual users more control over their machines and to help themselves out of common problems.
Who can get sudo privileges?
- Anyone who wants sudo privileges must first read and accept the terms set down by this policy.
- "Systems" people - those who have traditionally performed systems administration duties, and are responsible for maintaining particular software applications or systems can have sudo privileges on some CS systems upon request.
- Faculty can have sudo privileges on all computers that belong to them upon request.
- Visiting faculty, staff, students, and post-docs with a legitimate need for privileged access can get sudo privileges on their personal desktops upon request.
- All others may get sudo privileges with sufficient justification.
On what systems can you get sudo privileges?
- Personal workstations - Privileged access to a general purpose research workstation may be granted to specific users of that workstation with a legitimate need for privileged access.
- Research systems - Privileged access to computers designated for special-purpose research may be granted to users of those computers with a legitimate need for privileged access.
- Privileged access will not be granted to any user on the following systems:
- File servers.
- Mail servers, or any servers holding mail for multiple users.
- General-purpose multiuser computers.
- Servers and infrastructure computers.
Do's and Don'ts of Privileged Access
- Don't change the root password on your machine.
- Don't add user accounts to the system.
- Don't grant sudo access to any user.
- Choose an extrordinary password for your personal account.
- Don't run network daemons: i.e. no ircd, no ftpd
- Don't use sudo to run a shell: e.g. "sudo bash", or to just become root via "su".
- Don't use sudo to "su" to another user.
- If you make changes to your system, write down what you did.
- If you royally mess up your system, you're on your own.
- When in doubt, ask the system administrators.
Don't change the password of any users, especially root. The only password you are responsible for, and the only password you are allowed to change is your own. Changing the root or any other password will result in loss of privileged access and possible termination of your account.
Access to computer systems in the Computer Science Department are controlled exclusively by CSD-CF.
Being granted privileged access to a machine does not entitle you to grant the same access to others. Anyone who needs such access must request it from the system administrators. Granting privileged access to others will result in loss of privileged access and possible termination of your account.
This is especially important because your password can be used to exercise certain root privileges.
For similar reasons, we expect anyone who accepts these privileges to take extrodinary care in protecting their password. Never send your password in the clear over the network (change your password immediately should you do this). Never email your password. Never share your password with anybody.
If you think you need to run a network service, please talk with a system administrator.
We know it's a small additional burden to have to prefix each command with "sudo", but we, the systems adminstrators, would like to keep a handle on what people are doing to their systems so that chaos does not take over the department.
It is much easier to diagnose a problem if we know what has been done to a machine to create (or attempt to address) a problem. Similarly, it is much easier for us to understand how you cleverly solved some problem if we have a record of the actions you performed.
We use sudo, too. Log trails are an important part of enabling multiple people to manage the complexities of a large system.
It is a violation of Department and University policy to use the account of another user. Doing so will result in the loss of your privileged access and possible termination of your account.
Not for us; for yourself. The configuration of Linux systems in CS is constantly evolving. We will have to reinstall the OS on your system from time to time, although we will try to keep such reinstalls to a minimum.
Our official policy is that all machines should be able to be rebuilt using our automated kickstart process at any point in time. CSD-CF should be aware of any specific customizations made on a machine, to ensure your changes needs survive OS reinstalls.
If you want to make a change to your system configuration, please talk to the systems administrators first. We may have already provided a solution to the problem you are trying to solve. Also, what you want may be something we should be doing CS wide.
Extrodinary user customization is not a valid excuse to defer or forgo an OS upgrade when it becomes available.
The only thing we will do is reinstall the OS.
If you mess up your system in a small way, we may help you repair it at our discretion.
If a system is compromised by your action, you will be held accountable for the results.
If you're not absolutely sure of what you're doing, consult the system administrators. Doing so in encouraged, and saves everybody time.
If you have any questions about appropriate use of this privilege, please contact action@cs.