Darren J Moffat schrieb: > [...] 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: >
There is some residue from that in your posted man-page (in one place it says "... authorization or profile names can contain tokens ...". > pam_authorized.so.1 profile="MyCompany J2EE Logins" > > We dropped that yesterday just before I sent out the proposal because we > thought it might be hard to understand what it mean't. For example does > it mean any authorization listed in that profile or all of them ? In > your example it would mean any authorization. > > I agree that it is hard to understand. Profiles are a set of security attributes that apply together. They include authorizations, privileges and privileged commands with a capability to build profiles from other profiles. Using them as a loose collection of authorizations (in a disjoint sense, i.e. any of the auths will do) for this proposal, blurs the concept for admins and users and makes the RBAC framework harder to understand (IMHO). And using a 'profiles=..' PAM module argument is even more misleading, as you don't require the profile(s) listed. I admit that 'auths_from_profile=..' is clumsy. A somewhat related point: the 'wildcards in authorization names' part of the proposal is also very much underspecified. Usually wildcards of the some.auth.* variety (in user_attr or in profiles) match any authorization with that prefix (e.g. some.auth.for.a.special.feature). Bart explained in this discussion that for this case the match was meant to be single component only, which is counterintuitive, if you know the other concept. - J?rg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth at sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
