On 10/06/08 15:24, Joerg Barfurth wrote:
> 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).
That is the reasoning that led us to drop the feature. Thanks for the
note about the man page, I'll update it.
> 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.
The wildcards are meant to work as wildcards, matching the same set as
are matched when assigning authorizations:
- when they're used in user_attr's auths= it assigns all of the
authorizations underneath to a user,
- when they're used in pam_authorized auths= it accepts any of the
authorizations underneath.
The wildcard matches the same authorizations, it is only the
interpretation that differs ("assigned to user" vs. "sufficient for
access").
Bart
