[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ACM permission
Mark (and others who have commented on "too many permissions"),
Let's distinguish between compressing the list of permissions by
overloading permission names (eg. why not use "read" as an
attribute-level permission AND an entry-level permission) and dropping
permission names which means dropping functionality from the model (eg.
dropping "t" means you don't want to support the returnDN concept
anymore).
Here's one way to compress but not lose functionality, by reusing
permission names and relying on whether the aci is an entry-level or
attribute-level aci to make the difference--I've commented out the old
permission with a ";" along with an explanation of what replaces it:
"
Permissions (some of which apply to both entries and attribute):
r Read Read attribute values or Entries
w Write Modify-add values or rename an entry's DN.
; replaced with "d" o Obliterate Modify-delete values
s Search Search entries with specified
attributes or browse the specified entry
p searchPresence Presence only filters
c Compare Compare attributes
; replaced with "a" m Make Make attributes on a new entry
below
this entry
a Add Add an entry or attribute below this entry
d Delete Delete this entry or attribute
e Export Export entry & subordinates to new
location
i Import Import entry & subordinates below this
entry from some location
; replaced with "w" n RenameDN Rename an entry's DN
; replaced with "s" b BrowseDN Browse an entry's DN
; replaced with "r" v ViewEntry A read level entry permission
t ReturnDN Allows DN of entry to be disclosed in
an operation result
u Unveil This is the discloseOnError permission
g GetEffectiveRights This is get effective rights
permission
"
This reduces the permissions set from 17 to 12. But does that really
aid understanding ? The point being that although the admin now has a
smaller permission set that hasn't changed the fact that "w" on an
attribute means something different to "w" on an entry. Also, by not
overloading permissions we could, without confusion, mix attribute-level
and entry-level permissions in the same aci (note though that currently
an aci either contains entry-level or attribute-level permissions but
not both).
So, to dicsuss dropping functionality. First, Mark, I do not think it's
a good idea to drop filter/search and compare permissions--they just
seem too fundamental. I do however see two low hanging candidates to
drop, namely "t" and "p". "t" is concerned with supporting aliasing in
the ACM, "p" is a refinement on the search filter permission. I would
encourage those who think we have too many permissions to at first
consider dropping these guys. The reason I think returnDN is a good
candidate is that hardly anyone approves of aliasing (the iPlanet LDAP
server doesn't support it and anyone that does seems to regret
it--performance/complexity issues). The reason I think "p" might be a
good candidate is that it's really a refinement of "s" and could be
viewed as just too much functionality. Dropping "t" and "p" and using
the above "compression" gets us down to 10 permissions.
After that I think it gets more difficult to find easy stuff to throw
out: people have argued for the inclusion of "u" (disclose on error) and
the getEffectiveRights control is key to managing deployments of this
ACM so I think "g" (that says who can use this control) is also
important--Mark your controlType/"use" idea could work for that but I
think that deserves a seperate thread. The exotic looking "e" and "i"
are concerned with the complex moddn operation and I think they make the
required permissions for moddn easier to understand (see required perms
for moddn in section 5). We enforce an entry-add time permission at the
attribute-level too ("m"), again people argued for this, their point
being that just relying on an entry-level "a" and allowing _any_
attribute to be added based on that is just too coarse. Another point
here is that, for deployments where any of this extra functionality is
not required, then the management tool for acis (and let's hope there is
one!) can hide these extra permissions by not exposing them and
granting/not_granting them by default; the point being that in that the
tool can help hide the "too many permissions" complexity.
To summarize: the way to approach the "too many permissions" problem is
to first agree on the functionality we are willing to drop, if any.
After that whether we overload permissions or not is probably not
critical.
Rob.
Mark Davidson wrote:
>
> I have been thinking about simplifying the permissions
> in the ACM and also adding permissions for controls. How
> about:
>
> permissions for attributes: read, modify, create, delete
> permissions for entries: read, modify, create, delete
>
> and add control OID ass a possible target with a permission
> of use
>
> so:
>
> ACI = rights "#" target "#" generalSubject
>
> permission = "r" / ; read
> "m" / ; modify
> "c" / ; create
> "d" / ; delete
> "u" ; use
> ; permission u can only be used on controls
>
> target = "[all]" / "[entry]" / (attribute *("," attribute)) /
> "[controls]" / (controlType *("," controlType))
>
> controlType is defined in RFC2251
>
> Granting these permissions allows:
>
> Entry read - allows access to DN
> Entry modify - can change DN
> Entry create - can create an entry below this entry
> Entry delete - can delete this entry
>
> Attribute read - can read attribute
> Attribute modify - can modify replace attribute values
> Attribute delete - can modify delete attribute values
> Attribute create - can modify add attribute values
>
> Control use - can use control where aci is active (this
> replaces the g permission in a more
> general way)
>
> This does not give quite the same detailed level of
> control as the current scheme, but is much easier
> to understand from an administration point of view,
> rather that a protocol point of view.
>
> Mark