Subject: ACM permission

From: Mark Davidson <[email-masked]>
Date: Fri, 06 Jul 2001 13:43:39 +0100

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

---

From: robert byrne <[email-masked]>
Date: Mon, 09 Jul 2001 15:56:30 +0200

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.

---

From: John Haxby <[email-masked]>
Date: Mon, 09 Jul 2001 15:32:18 +0100

> After that whether we overload permissions or not is probably not

I think that there's something else to consider here.   Some poor
administrator has got to configure this server somehow.   With 17 different
permissions (and probably even twelve) there's ample scope for screwing up
and letting information leak out that they didn't intend to leak out.

For example (and this is just an example, it's not even vaguely formal and
probably not correct), suppose that an admin doesn't want to let people
read an attribute called "std" or even know that it is present.  Under a
really simple scheme, this means just disabling read access.  Under a more
complex scheme, make sure you can't read it or test for presence.  All well
and good.  Except that "std" only has a small set of possible values so you
can compare it against those.

Another example, you don't want people to test for the presence of an
attribute.  Do you just disable that.  However, there's nothing to stop
someone downloading the entire directory and using "grep" on it.  Or
searching for "(|(std=a*)...(std=z*))" (or a filter that tests for starting
with one of the 65536 unicode letters).

The point here is not that fine-grained access control is a good thing or a
bad thing.  It is rather a question of balancing the likelihood of an
administrator inadvertantly granting more access than they intended versus
not having as much control as they would like.

Personally, I would tend towards simplicity.   Is it really worth
differentiating between "presence" and "read" is probably a bit subtle and
definitely a minefield.   Is it worth having "compare"?  It might be.  At
one time, this was a really good way of storing passwords -- you could test
them but you couldn't read them (these days I'm not so sure: without extra
checks and complexity it just supports dictionary attacks and you're better
off putting that defense into the authentication mechanisms).

Finally, just let me point a little feature of VMS privileges which are
extraordinary in their richness and variety and usefullness.  Two of the 32
obviously let you acquire any privilege.  Four out of the 32 do likewise,
but very few VMS administrators knew what they were ...

In conclusion, then, don't forget that while you're deeply embroiled in the
subtle nuances of different sorts of access that (a) administrators are
unlikely to have that degree of skill and (b) hackers will find and exploit
any unlikely holes.  Keep It Simple.

jch