On Čt, 2016-10-27 at 15:10 +0200, Josef Moellers wrote:
> Recently I have come across the problem where the pam_krb5 module was
> inserted after the pam_unix module:
>
> account requisite pam_unix.so try_first_pass
> account required pam_krb5.so use_first_pass
>
> rather than something like this:
>
> account [success=1
> default=ignore] pam_krb5.so try_first_pass
> account required pam_unix.so
>
> effectively locking out EVERYONE including root!
>
> I was wondering if it was possible to describe PAM modules such that
> the
> correct sequence could be generated automatically given a set of
> desired
> modules.
> I was thinking in the direction of the systemd service descriptions
> eg
> specifying that a given module is only relevant for a specific set of
> groups
> pam_access
> use ACCOUNT:required
> pam_apparmor
> use SESSION:optional
> pam_krb5
> use ACCOUNT:required, AUTH:sufficient, PASSWORD:sufficient,
> SESSION:optional
> pam_unix
> use ACCOUNT:required, AUTH:required, PASSWORD:required,
> SESSION:required
> pam_env
> use AUTH:required, SESSION:optional
>
> and maybe also specifying that if one module is included, another one
> must also be included ("requires", "wants") or defining some
> hierarchy
> between modules.
>
> That way
> * a set of common group files (to be included) could be automatically
> generated given a set of desired modules ("I want Kerberos
> Authentication and some smartcard stuff if that is not available")
> * a manually crafted set of group files could be checked for
> correctness
> ("module A is required for module B").
>
> This is only a first thought ...
This could only describe the "recommended" way to set up a module, but
it cannot be a hard limitation on its use.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
_______________________________________________
Pam-list mailing list
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
