Zoltan reports that pam_cap.so does not seem to work when invoked from a Linux-PAM substack. We should try to understand what is happening here. For now, the recommendation is don't use pam_cap.so in a substack. Just include it at the top level of the App specific config file.
Created attachment 299743 [details] Patch for util-linux to make it Linux-PAM compliant This is needed for pam_cap.so to work with keepcaps and defer module arguments.
Using the 2.61-0 spec file I've added to https://bugzilla.redhat.com/show_bug.cgi?id=1919609 I had no trouble getting the util-linux su version from util-linux (that included the attached patch) to support ambient capabilities. This is the auth selection from system-auth that I'm using (it has the single pam_cap.so line) added over what Fedora-34 defaults to: auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth sufficient pam_fprintd.so auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular auth [default=1 ignore=ignore success=ok] pam_localuser.so auth optional pam_cap.so keepcaps defer auth sufficient pam_unix.so nullok try_first_pass auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular auth sufficient pam_sss.so forward_pass auth required pam_deny.so