Get Root On My Desktop

From CS Support Wiki
Revision as of 16:50, 14 October 2008 by Jpr9c (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Due to security concerns, we do not issue Linux root access to students by default. We will be happy to give you ownership of /usr/local and /etc/X11/xorg.conf so you are able to compile and install Linux programs locally and modify your display settings. In the case that a software installer requires root access, we'll install those packages for you - simply download them and send email to root, noting the location of the packages and any non-default build flags you would like used.

Many users have requested the ability to have root-equivalency to simplify the installation of Debian packages using the package management system; most of these requests are of the nature that they do not really require any special customizations to the code or kernel for the system. In this case, we ask that you actually route these requests through us, so that we can make those packages standard across all CS systems. Although this is somewhat less convenient for users, it helps keep us more aware of what our users need and are using, and acts as a forcing-function on root so that we update all systems and our automated deployments. It ultimately helps users by providing a highly transparent computing environment.

In general, we prefer that root access only be used in cases where the user needs to be updating system source (and running code) on a regular basis as part of their work.

These guidelines also apply to personal (privately owned) systems which are set up in the department on a [semi-]permanent basis (ie, not just a laptop or other portable); they are based on our duty to secure and protect our network, not our desire to take over your machine.

Should you require root access, we will grant it, but be aware of a few caveats:

Remote Filesystems

We do not export NFS to machines on which students have root-equivalent accounts, as this poses a security threat to our servers. If you want root and access to your home directory, you'll have to use mount.cifs, smb_fs or scp.

There is one exception to this: if the partition on which your home directory resides contains only members of your research group, and your advisor has approved it, we will export that partition over NFS to the computers of the members of your research group, regardless of whether root access has been granted on those machines. This requires a community of full trust among everyone on that NFS share.

Network Traffic

We will block, at the up-link, any inbound network connection that is not part of a TCP connection initiated from within the department, with the exception of SSH. That is, port 22 (SSH) traffic is the only connection that hosts outside our network are allowed to start with machines on which users have root.

All outbound connections (and the return responses) are permitted, so this will not interfere with your ability to connect outside CS. Within CS no traffic is filtered (hint: your testbed should always use systems inside the department unless you must go outside).

We will, on a one-off basis (by request to root), open up other "well-known" ports, if you have a demonstrated research need which cannot easily be satisfied by using the regular provided infrastructure. For example, this means that you can run your own copy of apache, but you can't run it on ports 80 or 443, unless you request that we specifically open those ports first. This helps us maintain a list of systems which we know are exposed.


Security is your responsibility; we expect you to keep the system up to date and patched against known vulnerabilities at all times.

Should we see evidence that the system has been exploited, we will remove it from the network, and will not allow it back on until we are satisfied that it has been secured; in practice, that generally means wiping the entire OS and reloading. No, we will not put it on the network to facilitate recovering your data before it is wiped; you'll have to use a burner or USB drive.

We require a root equivalent account for the systems group so that we can inspect the machine without having to hunt for it, if need be. We do not ordinarily look at these machines - such a response is event-driven (ie, we get a complaint from or

Data Integrity (aka local disk)

Like administrative access on our Windows machines, we make no assurances of data integrity on the local drive; please remember to keep all important data on the file servers. Our remedy will be reformatting in the case that the system becomes unusable or unstable. If your machine is removed from the network, you'll have to figure out how to move your data.

Hardware, OS and Software Support

If you want root, it's because you believe you can manage the administration of a machine and have expressed that by requesting root. That means you accept full responsibility for the system. We do not have the human resources to provide custom-install support for individual systems; this is why we use a standard distribution. We will not help you fix your hardware drivers, or debug your broken kernel, or help you compile and install, etc. We provide all that support on systems which run our standard distribution. If you are administering your own system and things suddenly break on you, even at a critical juncture, we can't necessarily help you.

We're not being mean, but we just don't have the resources. We provide a transparent, standardized environment for the department in order to make it easy for you to move to another system when things break at a critical moment. We are open, generally, to modifying our standard distribution by adding whatever software/package it is you need for your work to all our systems. We will test hardware to verify that it's not broken, and replace if necessary, but we won't get it working in your OS.