Record the Original Login UID with pam_loginuid

You will finish with a PAM session entry that records the authenticated user's login UID for an actual login entry point, plus a safe way to check the resulting process attribute. On this machine the module comes from libpam-modules version 1.5.3-5ubuntu5.7. Allow about fifteen minutes, including a rollback check.

1. Check the installed module and current login UID

Start with read-only checks. Ordinary users can run these commands; elevated privileges are not needed:

$ dpkg-query -W -f='${Package} ${Version}\n' libpam-modules:amd64
libpam-modules 1.5.3-5ubuntu5.7
$ test -r /proc/self/loginuid && cat /proc/self/loginuid
1004
$ ls -l /usr/lib/x86_64-linux-gnu/security/pam_loginuid.so
-rw-r--r-- 1 root root ... /usr/lib/x86_64-linux-gnu/security/pam_loginuid.so

The UID is a numeric process attribute, not necessarily the account that a later command switches to. The exact number and file metadata are host-specific. If /proc/self/loginuid is absent, the module can return PAM_IGNORE; do not treat that as proof that the module is broken.

2. Choose the right PAM service

pam_loginuid provides only the session module type. Its purpose is to establish the login identity at an entry point such as login, sshd, a display manager, vsftpd, crond or atd. It should run when the user first enters the system.

Do not add it to sudo or su. Those commands deliberately switch to another account. Recording the switched-to account as the original login UID would damage the audit trail the module is meant to preserve.

Find the service file that owns the entry point you intend to configure:

$ grep -Rns --include='*' 'pam_loginuid\.so' /etc/pam.d /etc/pam.conf 2>/dev/null
$ ls -l /etc/pam.d/sshd
-rw-r--r-- 1 root root ... /etc/pam.d/sshd

The first command may print nothing. That is a useful result: inspect the service's included PAM files before adding a second line. PAM stacks often use include or substack, so a line in a shared file can affect more services than its filename suggests.

3. Understand the session line

The module's normal configuration is a session rule with the module name and no argument:

session required pam_loginuid.so

The required control flag makes a failure matter to the session result, while allowing the rest of the stack to run. The manpage's complete example also uses required. Do not copy that whole example into an existing service: its authentication, account and password lines are a separate stack and may conflict with the distribution's setup.

require_auditd is an optional module argument, not a command-line switch. When present, the module checks the audit daemon and denies the login if it is not running. That is a deliberate availability and security trade-off. Leave it out unless the host's policy requires auditd to be available for every login and you have tested the failure path.

4. Add the line with a rollback plan

$ sudo cp -p /etc/pam.d/sshd /etc/pam.d/sshd.pam_loginuid.bak
$ sudoedit /etc/pam.d/sshd

Add one line in the existing session section:

session required pam_loginuid.so

Do not add the line twice, change unrelated controls, or add require_auditd during the first test. Save the file, then inspect the relevant section before attempting a new login:

$ sudo grep -n -C 3 'pam_loginuid\.so' /etc/pam.d/sshd
12-session required pam_unix.so
13-session required pam_loginuid.so

Spacing and line numbers vary. The important checks are one occurrence in the intended stack and a session module type.

5. Test a fresh entry point and verify the value

Open a new connection or login through the entry point you changed while keeping the original session available. Once inside the new session, run:

$ id -u
1004
$ cat /proc/self/loginuid
1004

The two values should match for a direct login by that user. The output is host-specific, so compare the numbers rather than expecting 1004. To see the value inherited by a child process, use a fresh shell rather than the old administrative session.

For a second check, inspect the service logs using the mechanism your system uses. On a systemd host this is read-only:

$ sudo journalctl -u ssh --since '10 minutes ago' --no-pager
-- No entries --

The unit name and output vary, and a successful session may produce no module-specific message. A clean new login plus the matching /proc/self/loginuid value is the useful verification.

6. Diagnose failures without guessing

If a new login is rejected, stop testing new sessions and use the still-open root session. A PAM_SESSION_ERR result means an error prevented the attribute being set, or that the requested audit-daemon check failed. Check the spelling, module path, PAM stack order and service logs. Do not add require_auditd as a repair: it makes a missing audit daemon a deliberate login denial.

If the host uses a UID namespace and the kernel cannot overwrite loginuid, the module can return PAM_IGNORE. Check the namespace and kernel behaviour before changing PAM policy. If the process has no /proc/self/loginuid, the same return value is expected according to the installed manual.

If you need to undo the example, restore the backup from the root session and retest a new login:

$ sudo cp -p /etc/pam.d/sshd.pam_loginuid.bak /etc/pam.d/sshd
$ sudo grep -n 'pam_loginuid\.so' /etc/pam.d/sshd
grep: /etc/pam.d/sshd: no such file or directory

The final command should normally print nothing after rollback. The example path is intentionally tied to the earlier placeholder; use the actual service file and backup name you chose.