2

I and a friend are administrating a number of virtual machines, each one dedicated to some task in the overall system. When we need to administrate them, we typically log in as root, since the only time we log in to the machines are when we need to perform administrative tasks in them. We usually do not use sudo, since every command we do will typically be a sudo command.

We would prefer to keep our accounts separate on these machines, to give us separate .bash_history, see when the other one was last logged in, etc. To do that, we will need two accounts with full root permissions.

One method is to change our normal user accounts to have UID=0 GID=0, i.e. the same as root. The question is: Are there any gotchas (i.e. unexpected or non-obvious effects) having several user accounts with the same UID and GID (in particular the same as root)?

P.S. I asked this over at Superuser, but that only earned me a Tumbleweed badge, so I am trying here instead.

5
  • If every command typically is a sudo command, why don't you do a sudo -s to get a root shell? Aug 14, 2017 at 18:12
  • That logs us in as root, and our command histories get mixed up again. Aug 14, 2017 at 18:27
  • @00prometheus You can keep histories separate even if you're running a shell as root. Aug 15, 2017 at 21:27
  • related: unix.stackexchange.com/questions/98797/…
    – cas
    Aug 16, 2017 at 1:06
  • So, I didn't read the man page of sudo properly, and @JohanMyréen had the right answer all along. sudo -s gives you a root shell but you keep your shell environment! Contrast with sudo -i. Nov 16, 2019 at 1:34

2 Answers 2

5

Obviously you are able to get to do (most of) your tasks as "root", as what counts is having the correct id and gid; however having both new accounts as root won't work as you wish to distinguish between you and your friend actions/logins.

Often the system or other software will get confused, and will show one user having the name of the other, a totally different user, or even the root name. (e.g. the system will get slightly confused for your purposes, having three users with the same id/gid); you might even be logging in, and left wondering why the system is saying you have got another login name.

I would advise you both using regular accounts, that belong to the sudo group, and having some discipline using sudo, avoiding abusing sudo su for getting in as regular root; the advantage of using all root commands as a sudo command as you mention, ignoring the slight inconvenience is that you have all logged according to the right user doing it.

From the security point of view, often the root user has several kind of limitations that the system might not impose to other users with the same id. One good example might be sshd by default not allowing remote root logins. There will be others.

Up to the point. Many things in Unix having been historically built assuming mainly root has id/gid 0. Trying to get around that in non-conventional ways is asking for some surprises along the way.

see How to add self to sudoers list? and How to run a specific program as root without a password prompt?

10
  • I am hoping for a solution where we don't need to use sudo, but still can have multiple accounts. As I mentioned in the OP, we never enter any of these VMs unless we are going to do admin stuff, so almost all of our commands will admin stuff. Using sudo for almost all commands is probably more inconvenient than having separate histories is an advantage. Aug 14, 2017 at 18:14
  • It is up to you wether you value more an inconvenience than having better logging/accountability. The point is that having multiples users with id 0 is not a good idea. Aug 14, 2017 at 18:16
  • Right, well that is what I suspected. So, I am back to sudo everywhere, and '| sudo tee' for every write-redirect, or just stick with using the root account. :-( Aug 14, 2017 at 18:34
  • 1
    Multiple users with id 0 is not just “not a good idea”, it's impossible. A user is defined by its user id. If you put multiple entries in /etc/passwd with id 0, you aren't creating multiple accounts, you're creating multiple sets of credentials for the same account. Aug 15, 2017 at 21:25
  • 1
    @gilled Well, not quite impossible, at least not on BSD, where there appears to be a practice in place of having an alternate root account called 'toor' with UID=0, used for instance to give different administrators different login shells. Aug 16, 2017 at 10:21
3

You are not just "giving your normal user accounts UID=0, GID=0". You are creating (or converting them to) two extra root accounts. UID=0 (and also GID=0) is what defines a root account.

Any system can have multiple root accounts, and they are ALL the one root account. A system doesn't even have to have an account called root. The root account can have any name or names.

They will be indistinguishable in any way from root (except possibly getent passwd fields like login name, home directory, and shell - but even that's not 100% guaranteed, depending on how/when login/ssh/whatever fetches those fields) because they ARE root.

There are many "gotchas" in doing this, pretty much all stemming from the fact that everything that is run by these accounts will be run as root.

This is a BAD idea. Don't do it. Use sudo instead.

BTW, freebsd systems often have a second root account called toor. It usually has /bin/sh (or bash or ksh or zsh or whatever) as the shell instead of the cthulhu-shell (csh or tcsh). This is not done to share root with another person, it's done for the convenience of making it slightly easier to use your preferred shell as root without changing the shell of the account actually named root (which has the small but real possibility of breaking things that assume that root's shell will be csh). tcsh/csh are indeed horrible sanity-destroying monstrosities and shouldn't be used, but it's trivially easy to type exec bash as soon as you su to root.


Finally, if you want separate history files for, e.g., sudo -i then edit ~root/.bashrc and add something like:

HISTFILE="~/.bash_history.${SUDO_USER:-root}"

That will set a different HISTFILE depending on whether root logged in (e.g. at the console or via ssh) or someone sudo-ed to root.

If you want HISTFILE to be unchangable within that shell (and any sub-shells it may spawn), add the following immediately afterwards:

readonly HISTFILE
5
  • 1
    I have used toor more often as a backdoor if anything goes wrong than to share accounts. Aug 15, 2017 at 14:32
  • I do understand the concept of references, and what it means for a reference to be aliased (in the formal sense), so I think I do understand why it could be dangerous to assign a UID to several accounts, depending on how relevant code is written. However, if the practice is taken into consideration carefully by all relevant programs (including the kernel), it could, with some effort, have been made safe. Unix is a very old system, and many old practices are taken into consideration. Aug 16, 2017 at 10:16
  • I was has simply hoping that this was such an expected old practice, and thus usually taken into consideration in the places where it becomes relevant. Your BSD example hints at it, so I was hoping that someone could give a definitive answer in this forum. Aug 16, 2017 at 10:17
  • this isn't a forum, it's a Q&A site. And definitive answers on this topic have been given here several times, including to your question.
    – cas
    Aug 16, 2017 at 11:31
  • My apologies, I will strive to use the term Q&A site here. Aug 16, 2017 at 12:30

You must log in to answer this question.

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