I run a server which is used by a group of individuals for e-mail, mailing lists, personal web homes etc.

I thought about ways to provide root access for other members to allow them handling problems on the server. But I don't like to give full root privileges to everyone.

What about the idea that two users must enter the password in sudo style to open a root shell? This would prevent a single user from hijacking the whole server. To increase security any number of needed user passwords above 1 could be used. As I see now this could be a nice way to provide root access within a group of people who know each other quite well and live nearby.

  • Do you know such a program?
  • what do you think about the concept in general?
  • 5
    Asking about the concept leads to discussion which isn't what stack exchange is about. You either want a technical solution, or confirmation it can't be done - debate on whether it's sensible should live elsewhere. Jun 24, 2011 at 15:50
  • 3
    personally I think you should read up on making it so sudo does not give full access. Which is part of the way it is meant to be used. Contrary to what ubuntu-ers may believe... sudo is capable of restricting the commands that can be run by what user. Not only that but could have it say... nopasswd for command cat user password for command vi and you might even be able to prompt for say the root password for rm though I'm not 100% sure you can change whether it requires your password or that of the user you're sudo-ing to for individual commands. Jun 24, 2011 at 16:37
  • 1
    If the users on the machine don't trust the people with root access, you have a problem. If I were a user in that position I would trust it even less knowing multiple people had their hands in the pot, even if they were tied. I would figure out what you need to do so that root access is NOT needed and make that happen instead.
    – Caleb
    Jun 24, 2011 at 19:48

7 Answers 7


Requiring dual approval for certain actions is part of some security policies; for example:

  • In banking, very large transactions typically require validation by two managers.
  • Launching heavy weapons such as nukes requires validations by two or more high-ranking officers or decision-makers.
  • Approving or rejecting a suggested edit on Stack Overflow requires two users with sufficient reputation to agree.

You'll note that this is not about authentication (e.g. typing a password to show that you're who you pretend to be), but about authorization, i.e. deciding whether a certain action is permitted.

For background reading, I recommend Security Engineering by Ross Anderson. Buy the latest edition if you can, but otherwise the first edition is available online. The most relevant chapter is “Access Control”; there are examples in the chapters on banking and nuclear command.

Unix offers a simple security model, with only two levels: user and superuser. This is both a strength (simple means less room for errors in the design and implementation of the system itself and of security policies) and a weakness (complex security policies cannot be expressed natively). If you're worried about a rogue user gaining root, don't give him root permissions. There are very few checks on what root does; the only constraint would be that the action of gaining root can be logged remotely, as can certain external actions (network traffic). A rogue user could pretend to want to gain root to do a certain thing and actually do another while hiding his actions from the other user. So you would not gain much security by requiring root access to be vetted by another user. Conversely, you would lose security by reducing the availability of root access (I gather you want to give less trusted users root access to serve as back-ups if something goes wrong; dual approval would increase the burden a lot).

Dual approval is useful for specific actions: Alice says “please authorize me do do X”, Bob says “I authorize Alice to do X”, and the system performs X (X can be e.g. transferring $1,000,000,000 from one bank account to another, or nuking Moscow, or rejecting an edit). If Alice says “please authorize me to do anything I want” and Bob agrees, all Bob is doing is echoing what you (the policy maker) already said, namely that Alice can be authorized to do anything. You might as well make Alice a sudoer.

I don't know of any existing system on unix to have multiple users approve specific commands in a sudo-like framework.


This may be what you are looking for:


sudo_pair is a plugin for sudo that requires another human to approve and monitor privileged sudo sessions.


The only way I can think of doing such a thing would be to create an account in /etc/passwd ( and /etc/shadow ) with uid 0 (for full access) or which belongs to the group(s) which provide proper access.

Then, set the password, telling the first person the first five characters and the second person the other five characters. Since passwords no longer have a limit of eight chars (like the old days), you can do this for as many people as you like (e.g. a 20 char sting with four characters being given to each of five people).

Of course, once in the account, they could just reset the password to something any one of them could use (in the case of uid = 0). So if you really have trust issues like this, then you have bigger problems on your hand than this.

  • After all, I have to say that I do not distrust the others. It's just that people trust me to manage their mailboxes and I cannot provide root access to somebody else without security measures. I trust them, they trust me, but not all users trust each other. Jun 24, 2011 at 14:46
  • 4
    The logic is not the problem. Giving parts of the root password to people doesn't work when different combinations of users shall be able to login as root. Either could a sudo-like program ask for some passwords and provide a shell directly. Or a userland program could collect different secrets to reveal a token that allows root login (token not printed to users, e.g. SSH key to login as root on localhost). There are algorithms that work with any set of users out of a group, see WP:Secret sharing; Jun 24, 2011 at 14:50

Just a minor comment on the mathematical issues here. One problem with splitting the password is that having half the password makes it easier to crack the rest. However, there are ways to specify two pieces of information that combine to give a key in such a way that either one piece of information by itself does not give any help whatsoever.

A rather simple example of this is to say: "The key is the sum of the two numbers, modulo 10". Then each person gets a number between 0 and 9 but that number by itself gives them no information. If Alice has 3, then the key could still be absolutely anything between 0 and 9 so she still has no advantage in cracking the code. It's only when Bob turns up and has 9 that together they can access the system with the key 2.

Of course, in a practical situation you'd want a way to ensure that Alice and Bob could enter their keys without the other seeing them.

For this situation, I'd agree with the others. Restricted access via sudo (read the manual) together with good logging. Then if they do try to do something bad, you'll have the logs (which they didn't get access to because you only gave them restricted access!).


You could have a process that runs in the background as root, that checks for certain conditions that both users must fullfill, and then copies in /etc/sudoers and removes it again after a few minutes. Both users could have to touch a file with with todays date as the filename in their home directory, for example. The background process could remove this file or disregard it after it was used once.

I also think that PAM has support for exotic types of authentication (like fingerprints and cards), so PAM might be worth looking into.


I don't know of any such program.

I think in general, it's flawed and gives you no more security than allowing a single user trusted access to limited commands.

Personally, I wouldn't give anyone I didn't know personally sudo access, even to a subset of commands, because it's too easy to miss something and give them access you don't anticipate.

Trust them, or don't trust them, building layers of not quite trusting them doesn't help.

  • 1
    Well, I understand your opinion but for me a single person is less trustworthy than two persons working together. If a person's probability of hijacking the server is 0<p<1 one could even mathematically proof that binding two accounts decreases overall hijack probability;-) In the extreme case of 5 passwords needed for server with 5 users (k=n) nobody could get access to a root shell without everybody else noticing. A little impractical, sure... ;-) Jun 24, 2011 at 14:20
  • 3
    One person has to convince one person they're trustworthy and they can abuse access. They either have to convince you (you give them root) or they have to convince the other person who has the other half of the key. In both cases you're screwed, in both cases, they convinced one person to trust them. Jun 24, 2011 at 15:48

It is probably easy to implement this by creating a superuser why has a long password, first half from the first authorized user, second from another (something like paul_john where paul and john are ordinary users).

The drawback, you would need such an account per every user pair but this would not require any changes in the software. These accounts could be listed in /etc/sudoers, authorizing them for the needed actions.

Be sure to have the policy the account must be immediately logged out if one of the authorized users go away from the terminal.

You must log in to answer this question.

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