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
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
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
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.