[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapACI permissions



Although it is tempting to 'imply' permissions as articulated in Jim's and Kurt's notes, this is
dangerous in that it allows some desired policies not be able to be expressed. An example
is the administrator who needs the capability to reset a user's password (the admin needs 'write''),
but should not / must not have the capability to read or compare that user's password values.
The counter argument to this would be to additionally deny the admin read and compare. But
that's more rules on the ACL. Also, if you go back to the requriements document, it is stated
that 'safer is better' - in this context, explicitly specify the permissions so you know what you
get instead of implying permissions. See S13, G1, and G2 in the requirements document.
Ellen



At 02:20 PM 3/22/00 -0800, Kurt D. Zeilenga wrote:
At 11:12 AM 3/22/00 -0700, Jim Sermersheim wrote:
>I think it would be very hard and not very useful to allow one to have 'a' or 'd' rights, and not 'w'. This is especially true when the identity with 'a' rights doesn't have 'w' rights to mandatory attributes. I think certain rights should imply other rights. Maybe a set of 'implication rules' is needed. Something like:
>


This is just food for thought:

Have used access levels ("write" => "read" => "search" => "compare") in OpenLDAP
for some time, I have only found a couple of cases (such as disallow search
of readable attribute) where discrete permissions would have been extermely
useful. These cases were enough to convince me that we should add support
for such.


What our devel code now supports both, it can be viewed (simplification):
        "write" is "=wrsc"
        "read" is "=rsc"
        "search" is "=sc"
        "compare" is "=c"

where the "=" sign is used to flag indicate the value is a discrete set of
permissions.  If you wanted to grant "r" but not "sc", you'd say "=r".