After Engineering IT installs a Linux system for a user, we're often asked "Now how do I get administrative access on it?"

Since the system is part of Engineering IT's managed Linux environment, our usual counter-question is "Why do you need root access?"

Our preference is to not issue administrative access to Engineering IT managed systems, and instead handle typical needs-requests through our normal support channels. Synonyms for administrative access in a Linux environment are root access, superuser access, sudo access.

Administrative access is usually request to manage software, accounts, or settings on the system. Each of those are better handled through Engineering IT, for the following reasons:

Software

Engineering IT's managed Linux environment includes a centralized system for software distribution, with the following features:

By centralizing our software installation, we add consistency and repeatability to the systems we manage. If we add a package to any one of your systems, it will be added on all of them - including new ones when they're first installed and or when older systems get reinstalled.

• One-off, manual package additions don't have that functionality and often get overlooked.

We can also easily and quickly leverage existing software packages used elsewhere in our managed environment. We can quickly install shared packages like Matlab or Mathematica without the manual install. Those package additions share the same consistency and repeatability listed above. We can also support multiple versions of software on a single system without conflict and still have ease of use, using environment modules.

• If you need a software package that's not already a part of our distribution, we can add it, and then leverage that software elsewhere.

Additionally, there are many ways to do software installation into your home directory that do not require administrative access or Engineering IT involvement. We can help you learn how to do this; please ask us.

Accounts

User accounts on Engineering IT managed Linux systems are UOFI Active Directory (AD) based. Managing those accounts in a central directory allows us to use the same password as other services. Active Directory based accounts create consistent access across systems.

• Accounts should only be centrally managed through the AD tools. Locally-defined accounts on the system can conflict with centrally-defined ones.
• We can support on-campus users, external collaborators, and long or short term guests accounts.
• We provide a web application so you can manage your group's users. Ask us for more information if you are interested in this tool.

Configuration / Settings

Similar to our software management, Engineering IT centralizes most of the main system configuration on our managed Linux systems. This means things like who can login, what network shares are available, what printers are available, what services are running, etc. By managing these settings centrally, we leverage consistency and repeatability. (For example, systems in CS will automatically get the Siebel Center printer queues added to them.)

If special services are needed on a system (like webhosting, file shares, etc.), we can work with you to find a sustainable way to provide those services.

Other factors to Engineering IT-only administrative access

Non-standard Linux installs

Engineering IT managed Linux installations are not like typical end-user desktop installations. The methods of system administration differ, and may conflict if a user tries to manipulate the managed system like a standalone desktop. It is safer to discuss your needs with Engineering IT and have them provision it for you than to assume what works on your home system will also work here.

Supportability

The more consistent your Linux system is with the rest of the Engineering IT environment, the easier it is for us to support you. Altering the system through self management can cause a number of problems:

• Filling up disk space by putting large datasets/software in unexpected places.
• Putting user data on unexpected file systems/locations of the system, and that can be ignored or lost during updates.
• Software installs can conflict with newer installs and patches, causing system and security updates to fail (and perhaps go unnoticed).
• Software installs can introduce security vulnerabilities to your system or accounts.

The support for Engineering IT to fix a system that's broken and has been altered outside of Engineering IT is very limited. In some extreme scenarios, Engineering IT may only support re-installation of the system back to its supported-base.

User feedback is important to us

There is value in the communication we receive from our users about their needs and usage of their systems. For example: you may not want to bug us with small software requests like having XEmacs installed on your desktop. But those requests are simple and give us insight into proactively modeling our environment. Requests like this give us the questions to consider what software should be installed across all your systems, or all systems in general.

The user communication on what does and does not work is very helpful to Engineering IT. Your feedback helps us build better, more usable solutions for you.

Exceptions / Requesting sudo access

Although Engineering IT strives to provide the best managed Linux environment possible, we recognize situations may arise where user administrative rights are necessary. Ideally, those circumstances lie outside of the conditions listed in this page. For example, root level access required for kernel level debugging, or to initialize services that cannot be run as a normal user.

In those scenarios, administrative access can be granted via the 'sudo' command. The root administrative password is not shared with users, but sudo allows an authorized user to run processes (or a shell) as root. Sudo permissions are not granted by default to users; they must be requested.

Risks / Scope of user administrative access

Sudo access can be granted in two ways:

• To specific commands or programs.
• To the entire system.

When sudo rights are granted without restriction to specific commands or applications the following risks apply:

• The sudo superuser has access to all processes, users, and files on the system. This means:
  • A sudo user can 'switch into' another user account without the password.
  • A sudo user can read other users files.
    • Besides privacy concerns, faculty should be aware of FERPA and other class privacy concerns when storing academic information on their system and permitting sudo permission to their students or group members.
  • A sudo user can control any process on the system, possibly making the system unstable or unusable.
  • A sudo user can do the administrative tasks listed above outside Engineering IT's managed environment.
    • These changes won't be recorded by our managed environment.
    • These changes could conflict with our managed environment and break some immediate or future functionality.
    • These changes could cause backups to fail and cause possible data loss.

Conditions for requesting user administrative access

The following information is required to request administrative access (sudo) permissions on Engineering IT managed Linux systems:

• The faculty member / PI / authorized user-decider for those systems agrees to it.
• The user acknowledges reading this page and accepts the risks and responsibility to preserve the system's functionality and data. 

Requests for sudo permissions can be sent to engrit-help@illinois.edu and should include:

• Your name and university netid.
• The systems (hostnames) you are requesting sudo permission on.
• A message from the faculty member granting permission, or contact information for the faculty member who can authorize sudo permissions.

Assuming the appropriate approvals are in place, sudo requests are usually processed within one business day.