We are having a little problem on a server. We want that some users should be able to do e.g. sudo and become root, but with the restriction that the user can't change root password. That is, a guarantee that we still can login to that server and become root no matter of what the other users will do.

Is that possible?

  • 32
    You can use sudo to grant permission for specific root-privileged application only. In that way, user will not be allowed to change the root password
    – SHW
    Commented Dec 16, 2013 at 8:48
  • 24
    WHY do you need sudo for these users. If you don't trust them, don't give them sudo access in the first place. Also note that ideally, root should not have a password at all, but you should use other means of authenticating. (Which the user will still be able to "hack", even if you would protext /etc/passwd) Commented Dec 16, 2013 at 11:48
  • 3
    What do those users need to do exactly? Commented Dec 16, 2013 at 14:20
  • 4
    What are they going to be doing with their root-privileges? There might be a better solution than what you are thinking of.
    – sparticvs
    Commented Dec 16, 2013 at 14:24
  • 23
    This is one of those "Can God make a boulder so large he himself cannot lift it?" type questions. If you have root access, you can do anything, which is why root access is best given judiciously. sudo and setuid can solve most problems.
    – bsd
    Commented Dec 16, 2013 at 16:58

18 Answers 18


This is practically impossible. First of all, if you grant them the power of becoming root, then there's nothing you can do to prevent them from doing anything. In your use case, sudo should be used to grant your users some root powers while restricting others without allowing them to become root.

In your scenario, you would need to restrict access to the su and passwd commands and open access to pretty much everything else. The problem is, there's nothing you can do to prevent your users from editing /etc/shadow (or /etc/sudoers for that matter) directly and dropping in a replacement root password to hijack root. And this is just the most straightforward "attack" scenario possible. Sudoers with unrestricted power except for one or two commands can work around the restrictions to hijack full root access.

The only solution, as suggested by SHW in the comments is to use sudo to grant your users access to a restricted set of commands instead.


There might be a way to accomplish this if you use Kerberos tickets for authentication. Read this document explaining the use of the .k5login file.

I quote the relevant parts:

Suppose the user alice had a .k5login file in her home directory containing the following line:
[email protected]
This would allow bob to use Kerberos network applications, such as ssh(1), to access alice‘s account, using bob‘s Kerberos tickets.
Note that because bob retains the Kerberos tickets for his own principal, [email protected], he would not have any of the privileges that require alice‘s tickets, such as root access to any of the site’s hosts, or the ability to change alice‘s password.

I might be mistaken, though. I'm still wading through the documentation and have yet to try Kerberos out for myself.

  • How did you do that cool reference to a comment? I looked at the source for your answer and saw () surrounding it. Cool secret hat!
    – Joe
    Commented Dec 20, 2013 at 23:24
  • @Joe The time a comment was posted is actually a link to the comment itself.
    – Joseph R.
    Commented Dec 20, 2013 at 23:33
  • @Joe Find the id (<tr id="thisistheid"...) to the comment (e.g. in Chrome right-click and Inspect element), then append it to the thread link with a preceding #. In your case (id = comment-162798) it looks like this: unix.stackexchange.com/questions/105346/…
    – polym
    Commented Jul 27, 2014 at 9:53
  • 1
    Thanks for the answer, I didn't know if I should accept this or that from @Michael Kjörling, I chose his because that has more description - needed by a noob like me :) However, yours was also helpful
    – 244an
    Commented Mar 14, 2015 at 12:17
  • @244an No worries. I would have recommended the same myself. :)
    – Joseph R.
    Commented Mar 16, 2015 at 8:40

We want that some users should be able to do e.g. sudo and become root,

Well, that's the problem sudo is designed to solve, so that part is easy enough.

but with the restriction that the user can't change root password.

You can, as SHW pointed out in a comment, configure sudo to only allow certain actions to be taken as root by certain users. That is, you can allow user1 to do sudo services apache2 restart, allow user2 to do sudo reboot but nothing else, while allowing the hired-as-system-administrator user3 to do sudo -i. There are howtos available on how to set up sudo like that, or you can search (or ask) here. That is a solvable problem.

However, a user that has been granted the ability to sudo -i or sudo into a shell (sudo bash, for example) can do anything. That is because by the time sudo launches the shell, sudo itself is out of the picture. It provides the security context of a different user (most often root), but has no say in what the executed application does. If that application in turn launches passwd root there is nothing sudo can do about it. Note that this can be done through other applications, too; for example, many of the more advanced editors provide facilities to execute a command through the shell, a shell which will be executed with the effective uid of that editor process (that is, root).

That is, a guarantee that we still can login to that server and become root no matter of what the other users will do.

Sorry; if you really do mean "ensure we'll be able to log in and use the system no matter what someone with root access does to it", that (for all intents and purposes) cannot be done. A quick "sudo rm /etc/passwd" or "sudo chmod -x /bin/bash" (or whatever shell root uses) and you are pretty much hosed anyway. "Pretty much hosed" meaning "you'll need to restore from backup and hope they didn't do anything worse than a slip of fingers". You can take some steps to reduce the risk of an accidental mishap leading to an unusable system, but you cannot prevent malice from causing very serious problems up to and including the point of needing to rebuild the system from scratch or at the very least from known good backups.

By giving unfettered root access on a system to a user, you trust that user (including any software they might choose to execute, even something as mundane as ls) to not have malicious intent, and to not mess up by accident. That's the nature of root access.

Limited root access through e.g. sudo is a bit better, but you still have to be careful to not open up any attack vectors. And with root access, there are plenty of possible attack vectors for privilege escalation attacks.

If you can't trust them with the level of access that being root entails, you'll need either a very tightened down sudo configuration, or to simply not grant the user in question root access at all through any means, sudo or otherwise.

  • 3
    I'm sorry my answer got all the hype (I don't quite get it!). Your answer raises excellent points and I hope it gets accepted. +1 to you, sir.
    – Joseph R.
    Commented Dec 16, 2013 at 23:49
  • @JosephR. sometimes a concise answer is preferred. Commented Dec 17, 2013 at 2:59
  • @DavidCowden Yeah, it seems this is the case here...
    – Joseph R.
    Commented Dec 17, 2013 at 10:48
  • 1
    @JosephR. No worries for me. The Stack Exchange community isn't always predictable, and questions that already have lots of upvotes do tend to attract more. Thanks for the upvote, though. :)
    – user
    Commented Dec 17, 2013 at 11:55

I'm assuming you want to make sure you have an "emergency admin" access, even if your actual administrator screws up (but other than that, you trust the main administrator fully).

A popular approach (although very hackish) is to have a second user with uid=0, commonly named toor (root backwards). It has a different password, and can serve as a backup access. To add, you'll likely need to edit /etc/passwd and /etc/shadow (copy the root lines).

It's all but fail-safe, but if you just need to safeguard against the "main administrator" changing the password without notice, then it will work. It's trivial to disable, by removing the toor account; so the sole benefit is having a separate password.

Alternatively, you may want to look into alternate authentication mechanisms, i.e. ssh keys, libnss-extrausers, LDAP etc.

Note that the admin can still screw up badly. For example, by blocking the firewall.

If you want to have a very secure system, consider using SELinux, where the unix user (e.g. root) is also coming with a role, which can be much more fine grained. You may want to give your admin root access, but only a restricted role (e.g. to administrate apache only). But this will require quite a lot of effort on your side to correctly configure the policy.

  • 6
    This doesn't actually prevent user toor from changing the root password; it only provides a second password to become root with.
    – alexis
    Commented Dec 16, 2013 at 12:30
  • 3
    -1, then. You're suggesting a backdoor password so that the admins can recover root access after they lose it??? That's just wrongheaded, and besides the pesky users could easily disable it, as you say. There are much more reliable ways to set up a backdoor.
    – alexis
    Commented Dec 16, 2013 at 14:03
  • 2
    @alexis That is what IMHO the author of the question asked for. Why give -1 for this? toor recovery accounts has been a common practise (although frowned upon) on Unix for decades. Commented Dec 16, 2013 at 17:08
  • 9
    If the only goal is to prevent against accidental password changes, this is a good answer. If the goal is to prevent anything malicious, this isn't much help. Since the OP didn't say what the goal was, we don't know.
    – Bobson
    Commented Dec 16, 2013 at 17:18
  • 2
    Which is why I stated that in my first sentence: "screws up ... other than that, you trust ... fully". This is really only a "support access" solution; not a security feature. Using additional root ssh keys achieves the same, without being hackish. Commented Dec 17, 2013 at 8:47

It's probably possible, at least in theory, to do this using SELinux. This allows you to set up much more precise rules about what a user or process is or isn't allowed to do. Even with SELinux, it may be tricky to make it impossible for a user to change the root password, but still able to do whatever they may need to do.

Really it depends on what the user who isn't allowed to change the root password actually does need to be able to do. It would probably be easier and safer to just work out what that is, and grant those permissions specifically using sudo.

  • 8
    While doing this with SELinux may in theory be possible (and I'm not convinced), claiming that it is without showing actual rules isn't going to help anyone. Commented Dec 16, 2013 at 22:00
  • @Gilles well actually, this is what SELinux was designed for. SELinux is a layer of permissions required in addition to standard POSIX permissions. On a properly configured SELinux machine, root access is meaningless since your true permissions are determined by the security context and object labeling.
    – tylerl
    Commented Dec 21, 2013 at 17:51
  • 2
    If you know how to do it, please answer Myth or reality: SELinux can confine the root user? Commented Dec 25, 2013 at 22:52
  • Theoretically, it may still be doable with SELinux; however, the setup of something like that would need to be more complex, to ensure a robust separation for ALL SELinux-related config files from the "normal" file-system (to which the root user has full access). In the end, the "easiest" method for such separation (with or without SELinux) would be to go with something like Kerberos, as mentioned by Joseph R.
    – ILMostro_7
    Commented Oct 14, 2014 at 9:12

The essence of root is to have unrestricted command of the system. You could tweak it with SELinux (there used to be a demo site where anyone could log on as root, but its power was crippled through the access system), but that's not the point. The point is that this is the wrong solution to your problem.

Now, you haven't said what your problem is, but if you don't trust these users to keep their hands off the root password, they have no business being root. If they need to administer the webserver, or various hardware devices, or the warp drive or whatever, set up a solution for that. Create a super-powered group, give it all the access it needs, and add them to it. If they need to execute root-only system calls, write some setuid programs.

Of course a user with that kind of access (and a bit of knowledge) could probably easily hack the system, but at least you're working with the OS security model, not against it.

PS. There are many ways to arrange root access for yourself without the password; for one, if you're in /etc/sudoers (without restrictions) you only need your own password to become root, e.g. with sudo bash. But you simply shouldn't need to go there.

  • But the problem is you can't stop attacker from gaining root through an exploit, SELinux provides defense in depth. Commented Dec 1, 2018 at 12:07

Perhaps you should consider letting the users have root access to a virtual machine or LXC container. That would allow them to have full root access to a system, without letting them prevent you from logging into the host or taking administrative actions.

  • This would be safer than many of the options IMHO.
    – Elder Geek
    Commented Apr 11, 2015 at 2:26

I don't know it will be practically feasible but here is one dirty hack:

  1. write a wrapper script/program which will copy the /etc/passwd file to some other location, before calling actual sudo
  2. Allow the normal user to use sudo
  3. Once he finished his task, or when he came out of sudo, restore the /etc/passwd file

I know, there are lot of plus-minus things you have to consider to achieve this. After all, it's a dirty hack

  • 3
    There's always the possibility that a malicious user will read this script and nuke the backup copy.
    – Joseph R.
    Commented Dec 16, 2013 at 9:07
  • This is also pretty much what vipw and friends do already.
    – user
    Commented Dec 16, 2013 at 9:10
  • Consider it program, and having only root access
    – SHW
    Commented Dec 16, 2013 at 9:11
  • 1
    root can edit the "other location" after sudo. Commented Dec 16, 2013 at 11:46
  • 5
    Why would you GRANT root access to a potentially malicious user??? As root, it is trivial to install a back door that does not depend on going through sudo and/or the wrapper...
    – alexis
    Commented Dec 16, 2013 at 20:34

The statement that sudo is just for granting root and there is no protection after that is blatantly false.

You use visudo to modify the sudoers file. Here's an example line:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command
  • redsandro is the username we're giving permission to. Put a % at the front to make it apply to a group.
  • ALL is a name for this rule. Sudoers can do a lot more than just grant global permissions. That's where it gets complicated though.
  • = needs no explanation
  • ALL:ALL reads as (who_to_run_it_as:what_group_to_run_it_as). This way you can allow running a command, but only in the context of a specific user or group.
  • NOPASSWD: tells it to turn the password prompt off.
  • /path/to/command lets you specify specific commands path_to_commmand, another_command

The thing to remember is that while sudo is mostly used by home users to escalate to root privileges, it can be and is used to control access to specific commands in a much more granular way.


  • from my other answer here
  • This answer explains how to set up sudo for limited root access, but it would be much better if the answer said so and where this should go.
    – user
    Commented Dec 16, 2013 at 9:02
  • @MichaelKjörling done Commented Dec 16, 2013 at 9:05
  • 3
    "The statement that sudo is just for granting root and there is no protection after that is blatantly false." Let's say I grant sudo vi access to a user because I want them to be able to edit system configuration files. That user then does :!/bin/bash inside a sudo vi session. How does sudo's ability to restrict what commands a user can execute through sudo help protect my system under those circumstances? (Nobody has said sudo can't be configured more tightly than an all-or-nothing sudo -i approach.)
    – user
    Commented Dec 16, 2013 at 9:09
  • 6
    Understanding the limitations of an approach is easily as important as knowing how to perform a task.
    – user
    Commented Dec 16, 2013 at 9:15
  • 1
    @MichaelKjörling, I think this is just an example. But to be clear, the right way to let users edit system config files is to let them run sudoedit. You can specifically identify which files they should be able to sudoedit. This is in man sudoers. Commented Dec 17, 2013 at 5:09

(I don't know ubuntu, but it should be similar to Fedora/Red-Hat)
The only thing I can imagine restricting access to changing the root password is not giving full root access, maybe with sudo, or using SElinux to restrict access to the password file... but I would not trust either with much access as root generally has unrestricted access and could update SElinux, or relabel the password file, or run some pre-prepred program to change the password.

If you don't trust them enough to not change the password you probably shouldn't be giving them root access. Otherwise I would guess you are trying to avoid accidents.

If you are only trying to protect your access to root, setup a program that can restore the root password, so even if it's changed it can be restored with minimal access. (sudo does well on it's own)


Your requirement is:

We are having a little problem on a server [...] that is, a guarantee that we still can login to that server and become root no matter of what the other users will do.

From your question it seems as though you are not facing random malicious users intent on destroying your system, but instead have semi-trusted users who may cause mischief now and then (students perhaps?). My suggestions address that situation, not an all-out assault by malicious users.

  1. Run the server inside a virtual environment. You will be able to mount the server's filesystem and replace altered files with known-good versions. Depending on the possible damage you anticipate, you could take a snapshot of all critical directories (/bin, /sbin, /etc, /usr, /var, etc.) and expand the snapshot to overwrite damaged files while leaving the rest of the system intact.

  2. Run the system read-only, e.g. from a DVD-R. If you can live with most parts of the system being static until the next reboot, this is a good option. You could also use a read-only backing store with a virtual environment or load the base system over the network, making changes between reboots much easier than writing a new DVD-R.

  3. Kernel modules. The kernel's Linux Security Modules (LSM) provide the basis for creating secure modules. LSM is used by SELinux, but is also used by a number of lesser-known and simpler systems, such as Smack, TOMOYO, and AppArmor. This article has a good overview of the options. Chances are one of those can be configured out-of-the-box to prevent write access to /etc/passwd, /etc/shadow, or any other file(s) you want, even by root.

  4. The same idea as #1, but when the server isn't in a virtual environment. You could have the server chain-load into a read-only OS such as a live CD, which would automatically mount the server's filesystem and overwrite the base system on each boot with known-good copies. The read-only OS would then boot into the main OS.

  5. Again, assuming these are semi-trusted users who are accountable to a higher-up (teacher/boss), the best answer may be Linux Audit. This way you'll know every security-relevant action taken and who took it (you'll know who took it because even if all users share the root account, they will have sudo'ed from their user account first). In fact you might even be able to parse the audit log in realtime and replace damaged files. /etc/shadow overwritten? No problem, just have the monitoring server instantly replace it with a known-good version.

Other technologies you may want to investigate based on your needs:


To complement the other answers, I'm going to assume the scenario is that you perceive losing control of root a rare situation, and that in those cases a server reboot is allowed. (After all, if you believe the machine has been compromised you will want to take it offline anyway.)

The great advantage of this is that there is nothing to configure. Your question becomes: "I've forgotten root password, how do I get back in?" And the answer to that is to reboot, and choose single-user mode when the machine comes up. That gives you a root shell without needing to know the password. At that point you can set a new password. (As well as go and repair any damage...)

  • 2
    No. As Michael so aptly noted, a malicious user can prevent root access without necessarily hijacking the password by simply messing up the binaries. Even the init=... approach may be prevented removing execute permissions from pertinent binaries. I think a better solution in this case, is to mount your root filesystem via LiveCD and (try to) fix the damage. Then again, if you believe the system has been compromised, you're better off restoring from backup anyway.
    – Joseph R.
    Commented Dec 16, 2013 at 23:46
  • Agreed @JosephR; discovering and fixing damage is complicated, and I'd just reinstall too. But I'm guessing the OP's concern was more about someone accidentally locking them out... deliberately hacking in a work or school situation is a bit suicidal. ;-) Commented Dec 16, 2013 at 23:56
  • 1
    Not necessarily. A truly malicious user combined with a careless/clueless sysadmin can escalate privileges undetected. I do agree that the OP's original intent was probably to ward off innocent mistakes rather than to guard against malicious intent, but the question was tagged "security" and we just ran with it, I guess :)
    – Joseph R.
    Commented Dec 16, 2013 at 23:59

If you clone your server into a VM (such as VirtualBox), you can give unfettered root access to people and still guarantee that you'll always have direct access to the guest operating system's partition(s), and therefore maintain final control over /etc/passwd and the like, since you will have root on the host system.

Of course, giving unfettered root access may still not be the right solution: if data security is at all an issue or your responsibility, you can't give root access away.


The requirement is not technically possible. As already eloquently commented, granting unlimited or even more limited sudo rights to a user means you trust that user. Somebody having evil intentions and enough technical ability and perseverance can go through any obstacles that are put in place.

However, assuming you can trust your users to not be evil-intentioned, you can make the restriction on password changing a matter of policy. You can create a wrapper for passwd program that will remind them "please do not change the root password". This assumes the source of the problem is that the users that are changing the root password are doing it due to a misunderstanding (like maybe thinking they are changing their own password after having done sudo bash).

Under special (rare) circumstances, if complete trust is not possible and it is not possible to break the sudo access to adequate but reasonably safe chunks, you might consider establishing organizational sanctions against password changing (or any other specified form of system tampering), arrange monitoring of critical resources so that it is not easy to go undetected to get around the set policies - and be public and transparent about the usage rules and monitoring.

The monitoring and discovery aspect is hard technical problem benefiting from another question should you choose to walk that path. It seems to me we would need to

  1. detect when a user changes identity to root and keep track of any created processes;
  2. log the process creations from then on to see who is the original user responsible for each process, and using remote host where the half-trusted users do not have access to send the logs;
  3. use some kind of system tracing to log what is happening and to later be able to discover who was behind the policy violation.

We would at least need to log opening of other than safe set of files for writing, process creation, exec(), and of course any attempt to change networking.

Implementation could be done by modified libc or (much better) system call tracing.

Of course, it is impossible to make such tracing and logging work 100% correctly, it is not easy to implement, and it also requires additional resources to operate. This would not stop the password change or other unwelcome system tampering, but it would make it (more likely) possible to find the guilty user or at least create an illusion that there is monitoring and make it less inviting for some evil minded users (but some problem loving hackers who see the fundamental futility of the technical measures put in place might feel encouraged to embrace the challenge and try to circumvent the system just for the fun of it).


The originaly formulated question is useless. It looks like the main goal is "still have login" so speaking about some emergency enter which keeps working for sure even with root access granted to another person. Cheers to Anony-Mousse who first noted It explicitly.

The problem is: If the owner has physical access to the box It can easily recover logical acces to the system (providing It is still alive:). If not - keeping root password will not rescue from e.g. sshd down or bad networks setup, thus the system is still not accessible anyway.

The topic about how to prevent the system from damage by a person with administrative privileges seems too broad to fit SE question format.

Speaking about remote emergency enter solution the best way is IPMI (I think) if It is available. The system owner can attache virtual drive anytime, boot from It and procced with system recovery.

If IPMI is not available any suitable virtualization technology can to be work-around, as have already been proposed above.


You can limit the access to sudo in your /etc/sudoers file

To fully explain the syntax of /etc/sudoers, we will use a sample rule and break down each column:

jorge  ALL=(root) /usr/bin/find, /bin/rm

The first column defines what user or group this sudo rule applies to. In this case, it is the user jorge. If the word in this column is preceded by a % symbol, it designates this value as a group instead of a user, since a system can have users and groups with the same name.

The second value (ALL) defines what hosts this sudo rule applies to. This column is most useful when you deploy a sudo environment across multiple systems. For a desktop Ubuntu system, or a system where you don't plan on deploying the sudo roles to multiple systems, you can feel free to leave this value set to ALL, which is a wildcard that matches all hosts.

The third value is set in parentheses and defines what user or users the user in the first column can execute a command as. This value is set to root, which means that jorge will be allowed to execute the commands specified in the last column as the root user. This value can also be set to the ALL wildcard, which would allow jorge to run the commands as any user on the system.

The last value (/usr/bin/find, /bin/rm) is a comma-separated list of commands the user in the first column can run as the user(s) in the third column. In this case, we're allowing jorge to run find and rm as root. This value can also be set to the ALL wildcard, which would allow jorge to run all commands on the system as root.

With this in mind, you can allow X commands in a comma delimited fashion and as long as you do not add passwd to this you should be fine


There is no 1/2 root :) Once you give root privileges they can do whatever they want. Alternatively you can use sudo to run a restricted bash shell or run the rbash without root privileges.

If you want to have a failsafe mechanism to login to the server as root, you can either create another user with uid=0 or create a simple cron which will reset the root password periodically.

  • It's easy to escape from restricted bash, see this Sans blog Commented Apr 11, 2015 at 6:03

Try adding a wheel group rather than using sudo. sudo allows a user to execute as though they are root which means it isn't any different than running:

su -

to become root. The root uid=0; the wheel uid=10. People use the names but the OS uses the uid. Certain commands cannot be run by a member of the wheel group. (If you use wheel don't make the mistake of adding root as a wheel group member). Take a look at Red Hat documentation if you don't know what wheel is.

Another option is to use an ssh key rather than a password. Assuming you can be sure the folks using sudo don't add their public keys to the ~/.ssh/authorizedkeys file this gets around any concern of the root password changing because root password is effectively ignored.

If you'd rather get around extending trust to these users (to not add their own public key) try using extended file attributes and using the Immutable bit. After creating your ~/.ssh/authorizedkeys file, and after configuring /etc/ssh/sshd_config and /etc/ssh/ssh_config as you like, set the Immutable bit. Sure, there're ways to screw with that too -- nothing is perfect.

In any system, insiders are the highest risk. The person who runs the show is at the top of the pile. A related thought pertains to contracts. Lawyers will tell you, "Never do business with someone you need a contract to do business with". Common sense tells us, "Never do business without a contract". When you find someone you trust enough to do business with, write the contract based on each other's needs.

All the submitted answers, including mine, fail to address physical access. Whomever has it, has control. If it isn't you then there's likely a way for you to get the person who does to physically access the machine in the event someone finds a way to prevent you from logging in, or if they find a way to log in even after you've attempted to prevent that from happening. Of course, if you've got physical access than there may not be a need for any of these things although implementing a couple should be considered anyway, if you're interested in NOT being inconvenienced.

-John Crout

  • sudo is hugely different from su -. This has been pointed out repeatedly, for example by SHW, Joseph R., myself, hbdgaf and quite possibly several more the comment field is too short to include...
    – user
    Commented Dec 17, 2013 at 16:05
  • All true, but irrelevant. You're discussing alternate ways to become root, and risks of granting root access, but nothing that has any bearing on “root access that can't change root password”. Commented Dec 17, 2013 at 16:11
  • True. The question is a logical oxymoron; It can't exist unless the installation is broken. What good is a user login/account where that user can't change their password, yet they have root access? Therefore the suggestions offered apply to what the questioner may have meant; not to the way they wrote the question. Any access control method has inherent risk.
    – John Crout
    Commented Apr 13, 2014 at 18:53

One way would be to ensure that /etc is not writable. By nobody, as long as there could be a sudoer around.

That could be done by mounting it over the network and ensure on the other side that the device can't be written.

That could be done by using a local device that prevents write access to it. (Lookup the write blocker hardware)

The important part is that the restriction has to apply outside of the root concept of that machine. A creative hacker will find its way around all obstacles you place on em within the environment he could control. So if root could change its password, so can a sudoer.

To be certain that the user also can't screw up your login abilities you have to have read-only mounted /bin and /sbin.

And you will have to have a script that periodically restores the network connection.

(As a sidenote: If you allow the sudoer only a very limited set of commands and for each of them secure that they can't break out of them / replace them etc., then you can prevent it while having /etc writable..)

  • Mounting /etc read-only, while perhaps possible (you'd have to be careful during the pivot-root in the initrd's boot scripts, for example), runs the risk of being a rather fragile setup. Also, there are many things a user with root access can do which cripples other users' ability to attain root privileges which do not involve making modifications in /etc.
    – user
    Commented Dec 16, 2013 at 11:57
  • @MichaelKjörling The setup is not fragile, I use it often (as read-only local mounts). Commented Dec 16, 2013 at 12:00
  • @MichaelKjörling I added some other elements you'll want to have read-only if you want to ensure you can still log in. So, the list of actions that have to be done if you go down that road is not so short, but its the only way that "is, a guarantee that we still can login to that server and become root no matter of what the other users will do." Commented Dec 16, 2013 at 12:03
  • I'll admit I've never seen the need to try it, but one thing I can definitely see that would be risky is how init is going to handle /etc/inittab being replaced under its feet. Or what the system will do if the initial and after-remounting /etc/fstab are different. And there's /etc/mtab. Other users may want to change their own passwords, which involves writing to /etc/shadow and possibly /etc/passwd. And mounting /etc read-only is still only a partial solution. I'm not saying it cannot be part of a solution, but it certainly isn't the first step I'd take in the OP's situation.
    – user
    Commented Dec 16, 2013 at 12:06
  • 1
    Yes. Doing this is dangerous and has severe problems if done wrong. Still as far as I can see its the only viable way to solve the OPs request for users who should be allowed to become root. Commented Dec 16, 2013 at 13:30

You must log in to answer this question.

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