Requesting administrative (sudo) access on Engineering IT Linux systems

Process and reasoning behind sudo access on EngrIT systems

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 two centralized systems for software distribution. They also have the following benefits:

  • The Linux Distribution's package manager.
    • Automated installation of common packages across multiple machines.
  • Engineering IT's software modules also known as environment modules.
    • Packages like the Nvidia CUDA toolkit, Matlab, and Mathmatica do not require manual installations. 
    • Multiple versions of packages are available to choose from.
    • Engineering IT software modules do not take up local disk space, which is beneficial for large software packages.
  • If you need a software package that's not already a part of our distribution, request it by emailing engrit-help@illinois.edu.

Additionally, there are many ways to do software installations into your home directory that do not require administrative access or Engineering IT involvement, ask us how!

Accounts

Engineering IT managed Linux systems use the UOFI Active Directory (AD). You can manage your group membership via a web app, ask us how!
Active directory accounts include:

  • On-campus users
  • external collaborators
  • long or short term guests accounts.

Configuration / Settings

Engineering IT centralizes most system configurations on 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. Engineering IT may only support re-installation of the operating system.

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.



Keywords:
requesting admin sudo access linux 
Doc ID:
81167
Owned by:
Glen R. in Engineering IT
Shared Services
Created:
2018-03-27
Updated:
2026-10-16
Sites:
University of Illinois Engineering IT