Nicolas Williams wrote: > On Fri, Oct 03, 2008 at 10:16:11AM +0100, Darren J Moffat wrote: > >> Mike Gerdts wrote: >> >>> other account required pam_authorized.so.1 >>> authsfile=/etc/MyCompany/loginauths >>> >> I considered that, but hadn't discussed it with Bart. At one point >> during the development of our proposal we had the ability to specify a >> profile to capture the case of multiple authorisations eg: >> >> pam_authorized.so.1 profile="MyCompany J2EE Logins" >> > > As we're doing with pam_user_policy, just have an attr key for > user_attr(4) and prof_attr(4) and then look for that key in the user's > user_attr($) entry and in the user's profiles (inlcuding the ones > granted by policy.conf(4). > > This key should name a file (possibly including as a URI, so that it > could be obtained via https, nfs, ...) that contains the authorizations > that should be used. > > Not only will that match what PSARC/2005/275 did, but it will actually > provide quite a bit of flexibility. > > If you want to support host-specific configuration then we can add a > host_attr(4) map if need be. >
In PSARC/2005/275, we are dealing with sets of records that follow pam.conf syntax, so it makes sense to represent these as files. But, we should avoid creating new configuration files when we don't need them. For this case, the existing prof_attr database already bundles authorizations, and we have a schema for representing them in LDAP, or other name services. So the use of a profile name, rather than a file name or URI avoids the need to create new files. --Glenn