This is for Ubuntu 14.04 and Centos 7.

I need to limit the number of users actively running as root. i.e. Logged in as root on the CLI.

Basically, I want only one user at a time to be able to run commands as root. The purpose here is auditing.

I looked into setting limits in /etc/security/limits.conf but the pam_limits.so module only seems to affect logins. Or login shells. Not sure. But whatever the specifics, it does prevent a user from SSHing to a box more than once, but does not prevent more than one user becoming root via "sudo su". Thus setting limits.conf can still allow more than one user being logged in as root at a time.

Here is the limits.conf line I tried that limits this:

root            hard    maxlogins            1

Next I tried limiting users in the @admins group. I figured that those users are the only ones allowed to sudo su to root (based on custom sudo rules we have in place).

@admins            hard    maxlogins            1

This seems to do what I want but seems clunky/wrong. Call it a gut feeling -- I don't quite have a handle on what I see as wrong about this one.

Finally, "Why?". Why do I have this requirement?

We are trying to implement controls to meet PCI-DSS 3.1 requirement 8.5 "Do not use group, shared, or generic IDs, passwords, or other authentication methods" -- emphasis on the "shared". In a Windows environment, you just grant users authorization to do whatever, and no one shares the primary Administrator account. Linux environments are designed such that for some things, you really want to be logged in as root. There must be a PCI-compliant way to solve this problem in a Linux environment.

  • "POSIX environments are designed such that for some things, you really want to be logged in as root." Could you elaborate on that?
    – gxx
    Jan 7, 2016 at 0:19
  • What's wrong with sudo? And how does limiting the number of logins for root improve auditing?
    – longneck
    Jan 7, 2016 at 0:51
  • Limiting the number of logins improves auditing because we can follow the su audit trail and be sure that admin X is the person currently logged in as root when event or command Y happens. If two or more admins are logged in as root and run a command, all you can see is that root ran that command. You can't tell which human ran it.
    – JDS
    Jan 7, 2016 at 15:11
  • @gf_ I was trying to think of an example of what I mean but I don't really have a good one. In some instances, it is much easier, and much less error-prone, to su to root and then run commands, than to sudo every command. Best example -- and it isn't a super good example -- I can think of is a pipeline where you need to sudo each command run in the pipeline.
    – JDS
    Jan 7, 2016 at 15:32
  • Alright...you could alternatively use sudo -i for that.
    – gxx
    Jan 7, 2016 at 15:37

1 Answer 1


This solves my issue: Log all commands run by admins on production servers


1) Install auditd

2) audit the execve syscall with these rules in audit.rules

-a exit,always -F arch=b64 -F euid=0 -S execve
-a exit,always -F arch=b32 -F euid=0 -S execve

3) Add audit=1 to grub.conf

Examples for Centos and Ubuntu:

grep audit=1  /etc/default/grub || \
( sed -i.bak -e '/^GRUB_CMDLINE_LINUX=/ s/" *$/ audit=1"/' /etc/default/grub && \
/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg )

grep audit=1  /etc/default/grub || \
( sed -i.bak -e '/^GRUB_CMDLINE_LINUX=/ s/" *$/ audit=1"/' /etc/default/grub && \
/usr/sbin/update-grub )

4) Place this line in these files /etc/pam.d/{login,kdm,sshd}

session  required                pam_loginuid.so

(I included this summary since linking to solutions goes against the Serverfault Way)

You must log in to answer this question.

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