Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When currently working on a linux server (I sysadmin 2) I have the 3 following use-cases:

  1. End-user use (e.g. personal or normal project groups)
  2. User problem solving and low-risk changes (e.g. Apache vhost changes)
  3. Real sysadmin work (e.g. configurig daemons)

We have 1 user account for everything (which is configured with detailed and correct groups for almost everything) in the NIS and generally it goes well.

The problem is that we currently open a root shell (sudo -i) for 2 & 3. This introduces risk because of full-access. Also we encounter errors from people with root access who overestimate their abilities (non-profit organisation so it's generally meant well).

I'd like to separate 2 & 3 by granting groups rights correctly (e.g. site team full access to apache but nothing else). Problem is I also don't want to grant the user accounts rights , i'd like to them to enter "admin mode" like is done now because it's easily loggable and makes people realise that they can cause damage now.

Is it possible to create multiple levels of power instead of just the normal user/root differentiation?

Other suggestions are ofcourse also welcome

share|improve this question
The most reasonable option seems to specify rights in /etc/sudoers and with ACL on the file system. Problem is that this does not really create multiple levels but just gives the normal user accounts further access – dtech Oct 13 '11 at 0:22
up vote 2 down vote accepted

You can use su to force people to change to an elevated user when doing things in category two.

Each user would have two accounts: $normal_account and $admin_account. Assign the needed permissions to $admin_account the the person can just do su $admin_account - to gain access to that account and do their admin work.

For class 3 functions I would say don't add another account just stop shelling out. Run your admin commands directly with sudo <command>. If you want to be really careful turn off password caching in the sudoers file.

share|improve this answer
Very good idea. Seems really good implementable. Stopping with shelling it also very well possible if most commands (e.g. reading and writing config files) don't require it which would be with the admin account. – dtech Oct 13 '11 at 0:28

You have two options, the most complex but most secure is mandatory access control (MAC) which can be accomplished via SELinux. The second is to configure your /etc/sudoers to grant a subset of control.

 User_Alias     OPERATORS = bob, tippy, george
 Runas_Alias    OP = root, operator
 Host_Alias     OFNET =
 Cmnd_Alias     PRINTING = /usr/sbin/lpc, /usr/bin/lprm


# The users in the OPERATORS group can run any command from
 any terminal.

linus ALL=(OP) ALL

# The user linus can run any command from any terminal as any 
user in the OP group (root or operator).


# user user2 may run any command from any machine in the 
OFNET network, as any user.


# user user3 may run lpc and lprm from any machine.


You can find more detail information at the Sudoers Manual

share|improve this answer
I hadn't thought of SELinux, but I hear it is very, very complicated and causes a lot of problems. Not sure if it's worth it. Am going to look into it though – dtech Oct 13 '11 at 0:21
Its not that SELinux causes a lot of problems. It can become very complicated. But, you don't get much more secure then SELinux. – Thomas Vincent Oct 13 '11 at 5:21
ofc, it causes problems because it is very complicated and hard to configure. I just think it's overkill because we want to protect users and admins from themselves, not because they have malicious intentions – dtech Oct 15 '11 at 9:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.