I've read that in order to prevent a user from change his own password, one must type:

passwd -n 10000 $user

But how do I prevent root user from changing $user's password as well?

Background: I'm trying to set up exclusive access to some directories, and figured a new user would be appropriate. Is it? I'm choosing not to compress + password protect those directories since most of them are over 1TB. Any hints?

EDIT: The reason behind preventing such action from root is that even users with root access should not be able to have access to some exclusive directories I'm trying to protect.

  • 5
    Why do you want to prevent root from changing the password? Also, you don't need a new user if your system has ACLs activated. – Sven Feb 27 '15 at 12:43
  • @Sven I've edited my question – victorantunes Feb 27 '15 at 12:49
  • 5
    Root can do everything and you can't prevent a root user to enter a directory with file system permissions. If you don't trust your root users, don't put unencrypted sensitive data onto the machine. – Sven Feb 27 '15 at 12:50
  • That's a valid point, and I believe ACL's are a bit complicated for me. Do you agree then that some easy-to-use CLI encryption tool would be appropriate? – victorantunes Feb 27 '15 at 12:53
  • 2
    That is entirely up to you to decide as I don't know your specific circumstances and users. Most likely it's easier for you to understand ACLs then for your users to deal with encryption tools though. – Sven Feb 27 '15 at 12:55

The reasoning for this question is questionable ...

To critique your desired solution of creating a new user -- even if other root users can't change new-user's password they don't need to since root can read any file or change the file permissions of the file -- they don't ever need to "be" that user."

I you have terabytes of data you want to prevent other users from accessing - don't put that data on the same machines those users have access to.

If you have terabytes of data on a machine with multiple users - why would you not what those users to access the data?

And we haven't even gotten to the point of talking about why have multiple root users you don't trust. Granted multiple root users is a good thing, however it sounds like you have root access for all users - friends are great, and let them in, but they don't need root.

Even using an ACL you can not prevent another root user from getting to the data - you(as root) created the ACL, they(as root) will modify it.

The only truly viable solution is what the various spook agencies invented a long time ago. Air gap'd machines.

Put your "top secret" data on a drive, and don't plug it into the machine with your friends. Or, install the drive onto a different machine without a zoo of root users, and which has no network access. You can probably get away with allowing this machine (file server) to have network access, since you're friends aren't likely to have Spook Grade hacker tools to gain access to this machine. Give only yourself access, and voila - isolated data. This sort of machine is very cheap to create. CPU, NIC and done.

If you "kind of want" to trust them, and/or, and only access this data from this (root-user-clutered) machine then only physically connect the drive when in single user mode, offline, and you are at the console.

There are perhaps some other creative solutions, however if it involves software it is not possible to isolate one root user from another root user.

ps: when referring to root, I am using that term to imply a true root user - not a user with sudo, etc.

  • Those were some very useful inputs. I'm accepting this answer since an air gap'd solution does indeed sound very robust for my case. – victorantunes Feb 28 '15 at 15:17
  • glad that my writing tone didn't put you off ... I must have been in a tissy mood that day because several of my posts were rather snide. – Daniel Mar 3 '15 at 16:56

Ultimately if you give someone root access to your system, you give them everything on the system, that's why it is important for you to trust people you give root to.


I suppose you could set an immutable extended filesystem attribute on /etc/shadow. That will prevent all changes to passwords, until the root user undoes the immutable bit. The command is "chattr +i /etc/shadow"

If you are provisioning root access to a professional sysadmin you're supposed to assume that they won't change the password if you ask them not to change it. Lastly, you could always switch to using Kerberos 5 or something centrally managed.

  • 1
    If you do try Kerberos, try using the excellent RH freeipa package to manage it. – Some Linux Nerd Feb 27 '15 at 22:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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