Grant Temporary PAM Groups with pam_group and group.conf

You will configure a PAM service to add a supplementary group only when a user, terminal and time rule match. The examples use the Ubuntu Linux-PAM package libpam-modules version 1.5.3-5ubuntu5.7, with the default rules file at /etc/security/group.conf.

Allow about 20 minutes, plus time to test the real PAM service. You need root access, a test account, the target service name, and an existing Unix group that should be granted. This guide changes authentication configuration, so keep an existing root session open while testing. A typo in a PAM stack can lock users out.

1. Check the installed module and its limits

Confirm the package version and module path before editing anything. These are read-only commands and do not need elevated privileges:

$ dpkg-query -W -f='${Package} ${Version}\n' libpam-modules:amd64
libpam-modules 1.5.3-5ubuntu5.7
$ ls -l /usr/lib/*/security/pam_group.so

The installed manual describes pam_group as an auth-type PAM module. It has no module options. It does not authenticate the user: it adds groups during PAM's credential-setting phase, based on the service using it. Membership from this module is additional to normal entries from /etc/group.

Checkpoint: identify the PAM service that should receive the temporary membership. Use its exact name, such as login, sshd or a service-specific file under /etc/pam.d. Do not add the module to every PAM service as a shortcut.

2. Check the group and make a backup

Choose a group that already exists and understand what access it provides. Reading the group database is unprivileged:

$ getent group PROJECT_GROUP
PROJECT_GROUP:x:1234:

Replace PROJECT_GROUP with the real group. The numeric ID and current member list will differ. If the command prints nothing, stop and resolve the group first. Do not create a new privileged group merely to make this example work.

Now back up both files that will change. This needs elevated privileges and creates recoverable copies in the same directories:

# cp -p /etc/security/group.conf /etc/security/group.conf.bak
# cp -p /etc/pam.d/TARGET_SERVICE /etc/pam.d/TARGET_SERVICE.bak

If the rules file does not yet exist, create it with root ownership and mode 0644 using your normal editor, then verify those properties. The PAM service file should already exist. Do not overwrite either file with shell redirection.

3. Add the PAM module to one service

Edit the target service's PAM file as root and add this line in its existing auth section:

auth    required    pam_group.so

The module accepts no options, so do not append a guessed file name or a group name. It reads /etc/security/group.conf by default. The required control flag keeps this module in the stack and records a failure, while the rest of the PAM stack continues according to its existing rules. Preserve the service's current ordering and controls.

Checkpoint: inspect the resulting file before starting a new login test:

# grep -nE '^[[:space:]]*auth[[:space:]].*pam_group\.so' /etc/pam.d/TARGET_SERVICE
12:auth    required    pam_group.so

The line number is only an example. If the file uses an included stack, confirm which file is actually read and avoid adding a second pam_group.so line accidentally.

4. Write one narrow group.conf rule

Edit /etc/security/group.conf as root. Each active rule has five semicolon-separated fields:

services;ttys;users;times;groups

This example grants PROJECT_GROUP to TEST_USER for the TARGET_SERVICE service on any terminal beginning with tty, all day:

TARGET_SERVICE;tty*;TEST_USER;Al0000-2400;PROJECT_GROUP

All of the first three fields must match. The service field is the PAM service name, the terminal field is the terminal name, and the user field can contain a user name, a Unix group prefixed by %, or a netgroup prefixed by @. The final field is a comma- or space-separated list of groups to add.

The time field uses two-character day names and 24-hour times. Al0000-2400 means all seven days for the whole day. A range whose finish is earlier than its start continues into the following day. Use a narrow window when practical. For example, this grants access to members of the Unix group project-admins on weekdays from 09:00 to 18:00:

TARGET_SERVICE;tty*;%project-admins;Wd0900-1800;PROJECT_GROUP

Logic lists use | for OR, & for AND and ! for NOT. The simple wildcard * may be used only once in the relevant ordinary list. Unix group and netgroup entries do not support wildcards or logic operators. Lines can continue with a backslash, and text after # is a comment.

5. Test in a fresh session

Start a new session through the target service as TEST_USER. Existing shells do not gain or lose supplementary groups when you edit the configuration. For an SSH service, open a second terminal and connect normally; for a local login service, use a separate console or desktop login.

Once logged in, inspect the process groups without elevated privileges:

$ id TEST_USER
uid=1001(TEST_USER) gid=1001(TEST_USER) groups=1001(TEST_USER),1234(PROJECT_GROUP)
$ getent group PROJECT_GROUP
PROJECT_GROUP:x:1234:TEST_USER

The exact IDs and ordering vary. The useful check is that the new session includes PROJECT_GROUP. Then test the actual file or device access that the group is meant to control. Seeing the group in id proves the credential was added, not that every application will use it correctly.

Test the negative cases too: log in through a different PAM service, use a user outside the rule, and try outside the time window. The group should be absent in each case. If you cannot perform a fresh login safely, do not treat an existing shell as evidence.

6. Diagnose a rule that does not match

Check the four values most often confused: the PAM service name, the terminal name, the account name and the current time. A rule for sshd does not automatically apply to login, and tty* does not mean every graphical or pseudo-terminal name. Capture the session's terminal with:

$ tty
/dev/pts/3

If your session reports a pseudo-terminal such as /dev/pts/3, a rule beginning tty* will not match it. Change the terminal field only after checking the service's actual PAM context and the security consequences. An overly broad wildcard can grant the group in more places than intended.

Review system authentication logs using the host's normal logging tools if the module reports a PAM error. A missing user can produce PAM_USER_UNKNOWN; failure to grant a group can produce PAM_CRED_ERR. These are module return values, not shell commands. Do not add module options to silence them, because this installed module recognises none.

7. Treat the security boundary as incomplete

The Linux-PAM manual warns that temporary group membership can be retained through a user-created setgid binary if the user can write to and execute from a suitable file system. For this module to provide meaningful security, writable file systems available to the user should be mounted nosuid. This is a host-wide deployment decision, not a harmless switch to add while testing.

Do not use pam_group as the only control for highly sensitive access unless you have reviewed the mount layout, setgid behaviour, service stack, logs and recovery path. The granted group also applies in addition to /etc/group, so review the effective access rather than assuming the PAM rule replaces ordinary membership.

8. Undo the change

To remove the rule, delete or comment out the exact line in /etc/security/group.conf, then remove the pam_group.so line from the target PAM service. Existing sessions keep their current credentials until they end; start a new session to verify the group is gone.

# cp -p /etc/security/group.conf.bak /etc/security/group.conf
# cp -p /etc/pam.d/TARGET_SERVICE.bak /etc/pam.d/TARGET_SERVICE

Use the backups only if they are the copies you made for this change. Keep the second root session open while testing the restored configuration. Do not restart a display manager or remote access service as a first response: a fresh login is usually enough, and an unnecessary restart can disrupt other users.