Nicolas Williams wrote: > On Mon, Oct 06, 2008 at 07:02:49PM +0200, Bart Blanquart wrote: >> On 10/06/08 18:33, Nicolas Williams wrote: >>>> ... pam_authorized.so.1 profile="Login to %f" >>> Me too, but I'd prefer if we stored this in /etc/security/policy.conf, >>> not in pam.conf module arguments. >> How would that permit per-stack authorizations, if you want to >> differentiate authorizations based on the service being invoked? > > But do we need per-service authorizations? If we do, then simply add a > service name token (%S) to the profile configured in policy.conf(4) for > pam_authorized.
That just moves the "upgrade burden" from pam.conf to policy.conf. One of the main reasons we choose to have the configuration available as module options rather than in some config file was to allow for multiple different stacks to have a completely different use of pam_authorized and to allow multiple pam_authorized entries with a different config in multiple places in the same stack. For example: # sshd pubkey just needs the "default" solaris.login.remote auth # but for kbdint we need our site specific site.foobar and example.login sshd-pubkey account required pam_authorized.so.1 sshd-kbdint account required pam_authorized.so.1 auths=site.foobar sshd-kbdint account required pam_authorized.so.1 auths=example.login gdm account required pam_authorized.so.1 auths=site.foobar Allowing multiple pam_authorized entries in the same stack provide the ability to do AND operations. Personally I'd prefer we had pam.conf module arguments than adding more cruft to policy.conf. -- Darren J Moffat
