Using pam_succeed_if.so to allow passwordless su for a given group

Question

I have a service user srvuser and a group maintainers. How can I allow only group maintainers to become srvuser with su command? I tried editing /etc/pam.d/su:

auth            sufficient      pam_succeed_if.so use_uid user = maintainers and user ingroup maintainers

But and is apparently not allowed in the conf file. Any way to get around this?

Solution

Nothing in the documentation of pam_succeed_if seems to indicate that it would support multiple conjunctions, so you'll need to do it outside the module.

If you were writing a required rule, it would be simple to combine them by creating two separate rules:

auth  required  pam_succeed_if.so user = srvuser
auth  required  pam_succeed_if.so use_uid user ingroup maintainers

But with a sufficient rule, as in one that terminates processing when a positive result is returned, this would not work, but turn into an or condition instead. But PAM supports a sort of flow control, allowing to skip some rules based on the return value of a previous module. See the documentation here.

This should flow through to the pam_permit rule as long as the pam_succeed_if modules return true, but skip to the following rules if they return anything but a success.

auth  [success=ok default=2]  pam_succeed_if.so user = srvuser
auth  [success=ok default=1]  pam_succeed_if.so use_uid user ingroup maintainers
auth  [success=done default=ignore]  pam_permit.so
... # other modules

As you can see, the syntax is horrible, and I would suggest testing the configuration before even trying to actually use it anywhere.

---

Of course, to allow members of a some group to run a process with the privileges of another user, you don't necessarily need su, sudo or PAM. With the usual file permissions, you could create a setuid binary, and only allow members of a given group to execute it:

# chown srvuser.maintainers ls
# chmod 4510 ls
# ls -l ls
-r-s--x--- 1 srvuser maintainers 118280 Mar 26 19:03 ls

The downside here is that unlike su and sudo, running a setuid binary is not logged anywhere, and that the setuid binary can be modified or deleted by processes running as the target user. To work around this, you could create a simple fixed-function wrapper program, to log the execution, setuid to the target, and then exec the actual command.

Comments

[phemmer]

Just curious, why not use sudo which has a very simple way to do this?

[TheMP]

Short answer would be weird requirements for sudoers file from security people. They didn't say anything about pam.d though ;).