I'm setting up a server which other people will have sudo access to via ssh. They can install stuff and make changes as they see fit, however I still need to manage the server, install patches and software updates etc.

I'm wondering if I keep the root password so that I can always do what I need to, can I somehow disable people with sudo from being able to change it with sudo.

  • 3
    This sounds like a job for (removes civilian cloths revealing a superhero costume) OpenVZ or Usermode Linux or Jails or Zones!!!
    – chris
    Aug 9, 2009 at 15:48
  • the question is perfectly legal.
    – drAlberT
    Sep 28, 2009 at 16:44
  • Just do 'rm /usr/bin/passwd' that way they can't change it... :-O
    – captcha
    Oct 26, 2015 at 23:47

12 Answers 12


You have to think about it like this. If you give them the root password, or a route to it, you're essentially asking "how can I give them root except for all the times when I magically don't want them to have it". And the answer is "you can't. Computers don't work that way."

  • Wouldn't it be great if they could. I, for one, await the window manager with a Focus-Follows-Mind mode. Aug 9, 2009 at 8:17
  • David: Maybe eventually :-) That would be excellent. Aug 9, 2009 at 15:37
  • 1
    Actually, Andriod, I think it is. Maybe not the answer wanted, but an answer none the less.
    – Rob Moir
    Aug 12, 2009 at 9:58
  • 1
    You can, any RBAC system allow you to accomplish a similar job. Saying computers don't work that way, computers are done to work the way creators are smart enough to make them do!
    – drAlberT
    Sep 28, 2009 at 16:43
  • 1
    Hmmm.. is it possible to do this with SELinux?
    – pjc50
    Jan 15, 2010 at 10:27

You can selectively allow certain commands with sudo, but you must be careful to not permit programs that allow shell access, writing to sym links, or one of a few dozen other problems. Here's a page on secure sudo scripting: http://www.kramse.dk/projects/unix/security-sudo-script_en.html

You could always hope that they don't know about the chattr command ;-)

  • 1
    +1 for chattr, or +i ;)
    – hayalci
    Aug 9, 2009 at 13:42

I think the answer here depends on whether you are trying to stop them from maliciously changing the password to keep you out, or just carelessly getting the password because they forgot you need access. In the former case you are going to have a lot of trouble. I don't know under what circumstance you would give users root access to the box but still be worried about this, but the best you can do is try to limit their access to commands through sudo, which as others mentioned is tricky at best. In the latter case it seems like the solution would be to create yourself a user with sudo privileges. No one is going to accidentally change the password on your account so you don't have to worry about someone just making a mistake, or even changing the password for a good reason and forgetting to tell you about it because you can always get in with your account and change it back.

  • 2
    In either of those cases -- malice or incompetence -- you really, really, really don't want to be giving them root access at all. +1 for the "keeping a separate sudo-capable account" around.
    – womble
    Aug 9, 2009 at 4:12
  • Having a separate sudoer account is is a great idea.
    – Akilan
    Aug 9, 2009 at 11:47

SELinux can do what you're looking for, although it's like using a nuclear-powered planet-smashing battleax to swat a fly, or whatever the Hitchhiker's quote actually is. If you're set on Linux rather than Solaris (and its shiny RBAC), the easiest-to-implement option will likely to be to configure sudo to only allow the commands necessary.

  • 1
    Actually getting the sudo permissions correct to absolutely contain someone is a steep hill. Once I've got a program running as UID 0, I've got just a thin paper wall between me and an actual root shell. Of course, that's assuming clever and hostile users, but still.
    – chris
    Aug 9, 2009 at 15:45
  • Just because you're paranoid, it doesn't mean they're not out to get you. Aug 11, 2009 at 2:42

There are a few options:

  • You could use PAM (Pluggable Authentication Modules) to allow you to log in as root, regardless of what they set the password to. There are a lot of modules available, so I'll just leave this one hanging.
  • You create 'a second root user' by opening /etc/passwd and adding a new user with the same UID as root (0). Then add a password into the /etc/shadow file for that specific user. This will allow you to log in as root and even if they change the password for 'root' - your login still works.
  • Create a shellscript that is run periodically to check if the hash of the root user in /etc/shadow for root matches the one you want it to be. If it's not, the hash is changed back.

As others have pointed out, giving root access will allow them to do absolutely what ever they like on the system and if they really want to lock you out; they can. The options above however make it harder or less transparent to them.


Solaris has solved this by making root as a "role" so nobody has a root password and root user cannot log in to system. To prevent anyone from locking you out, there are lots of fine grained security options; so you can have them do most of the root things with "pfexec" (equivalent of sudo) but you can be able to prevent them from revoking your sudo priviledges.

[[ I'm not a solaris fan, but there are some very good things in solaris other than ZFS and DTrace. Too bad If oracle extinguishes the flame ]]


Instead of preventing them from changing the password, just make it a policy that they are not permitted to do so. Then you can set up something like auditd to watch the password file and notify you of changes.


What you want isn't reasonable. Giving root to people in any form will allow them to wreck your system. Even if their access is via heavily regulated sudo, a clever or malicious or really deranged idiot will be able to cause mayhem.

You either trust them or you don't.

If you're supporting their needs and the firm as paying you to support them, it is their machine, not yours; you're only there to keep it working despite whatever foolish things they do. Maybe after they roast it a couple times you can ask your boss if you can give the clients less access or otherwise the firm will have to keep paying you to fix the mess. Whatever -- it's their dime.

If it is your computer and you're doing these others a favor, ask them politely to be nice.

That said -- you can always boot from CD (or other read-only media). They'll still be able to wipe out the other filesystems or mount over /etc with their own /etc, but all you need to do to get the system back to some rudimentary level of functionality.

You can also use something like openvz and give each user their own instance. They won't be able to wipe out the whole system and they'll be able to install their own software in their slice. Lots of places use this for web hosting where they give the clients "root" in the VZ slice.


If you can't use a system with RBAC, like Solaris, HP-UX or AIX, you can implement RBAC on Linux with the grsec patch.


That's where a middle-layer access user type come in need. I think if a user type would exists with customizable privileges (standard access plus some of the root accesses) it would be nice. Also to prevent this user from changing for example password file (as the linux is based on files) we could restrict the password file access permissions for not being available to that user. then put a password for BIOS to prevent user from changing /etc/shadow file with a third-party bootable flash or CD.

The above is just a theory for linux developers and not sure if it's possible...


prevent them to change any password:

chattr +i /etc/shadow
  • 1
    Then they run chattr -i /etc/shadow with sudo and are back in business.
    – koenigdmj
    Aug 9, 2009 at 0:23
  • 2
    Not to mention the fact that it means that no other user can change their password either, which is really bad.
    – womble
    Aug 9, 2009 at 4:13
  • 2
    I already wrote "prevent THEM to change ANY password". not many sparetime admins know chattr. In the past it was very usefull for me to know and use chattr.
    – ThorstenS
    Aug 9, 2009 at 9:10
  • Obscurity is not the same as security, thus chattr is not a secure solution.
    – Sam
    Oct 26, 2015 at 23:42

It doesn't matter why users ask questions. The answer "You can't" is not true! The answer is actually listed at the bottom of the "man sudoers" page. It's called a "Whitelist with an exception", and I am actually implementing this for the company I work for. Here's what you do -

  1. Add the users you want to lock down to a group
  2. Edit the sudoer's file - visudo
  3. Add this to the sudoer's file (testgroup is the group you added the users to)

%testgroup ALL = (ALL) ALL

%testgroup ALL = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd root

%testgroup ALL = !/usr/sbin/visudo

  1. Done

This prevents the sudo users from changing the root password but allows all others to be changed AND prevents them from editing the sudoers file. There are other things you should probably add to this, like preventing a user from changing the group they're in, but you hopefully get the gist.

  • 1
    You might want to hold off on security pronouncements until you learn a bit more. To drive a truck through your rules above, try sudo vi /tmp/foo, then :!/bin/bash, then passwd root.
    – MadHatter
    Jun 25, 2015 at 16:29
  • Yes, this is not a polished solution, but it answers his question.
    – Eric
    Jun 25, 2015 at 16:31
  • 1
    My point is it's not a solution at all.. If you were to try to polish it, you'd find out that the observation "you can't" is in fact correct. It's true that you can secure a system with sudo, but you will never manage it by allowing them to do everything-except-the-listed-exceptions. It's literally impossible.
    – MadHatter
    Jun 25, 2015 at 16:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .