When you support mission critical systems it is critically important to know WHAT is running on your systems and WHO is running it. In the past it was sometimes a chore to tell which UID ran a program. This was especially true in the early days when programs fork()‘ed and execve()‘ed after escalating privileges.
The which UID ran a program mystery has been mostly solved (I say mostly because user namespaces throw a few kinks into the equation) by auditing and the PAM loginuid module. PAM loginuid helps solve this problem by maintaining a /proc/PID/loginuid entry with the UID of the user that interacted with a service (e.g., ssh) that is configured to use pam_loginuid. You can get a list of PAM loginuid’ed services with grep:
$ grep --files-with-matches loginuid /etc/pamd/ | paste - - - - -
atd crond gdm-autologin gdm-fingerprint gdm-password
gdm-pin gdm-smartcard lightdm lightdm-autologin login
lxdm pluto remote sshd systemd-user
Once the loginuid is set the original UID will follow process creation:
$ id
uid=1000(matty) gid=1000(matty) .....
$ cat /proc//loginuid
1000
$ sudo -i
$ id
uid=0(root) gid=0(root) groups=0(root)
$ cat /proc/$$/loginuid
1000
$ bash
$ cat /proc/$$/loginuid
1000
Now this gets especially interesting when you enable auditing. If auditing is enabled and privileges are escalated each event will contain an AUID with the value of the actual user that ran a privileged command:
type=SYSCALL msg=audit(1477500276.323:92205): arch=c000003e syscall=231
a0=1 a1=3c a2=1 a3=3 items=0 ppid=30493 pid=30544 **auid=7005** uid=7005
gid=7005 euid=7005 suid=7005 fsuid=7005 egid=7005 sgid=7005 fsgid=7005
tty=pts1 ses=1196 comm="dmidecode" exe="/usr/sbin/dmidecode" key=(null)
No more seeing uid=0 and having to track down the underlying user or application by digging through logs. This is also incredibly useful when conducting RCAs and doing postmordems. To learn more about this feature check out pam_loginuid(8), the pam_loginuid source and the following link from the samhein team.