Resent-Date: Thu, 12 Jul 2001 23:16:19 -0700 (PDT)
Sender: Robert.Byrne@Sun.COM
Date: Fri, 13 Jul 2001 08:14:29 +0200
From: robert byrne <robert.byrne@Sun.COM>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
To: ietf-ldapext@netscape.com
Subject: too many permissions in the ACM
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com>
X-Loop: ietf-ldapext@netscape.com
Resent-Sender: ietf-ldapext-request@netscape.com
Folks,
This is continuing the issue Mark and others raised in the "ACM
permission" thread about the fact that there are too many permissions in
this model and the consequent complexity/manageability/security
implications of that. In this thread I want to focus on resolving this
problem as best we can.
If you think that too-many-permissions is a flaw in this model then you
need to propose a way to fix that. Presumably the way to do that is to
drop some of the functionality that this large permissions set is
providing. However if you do that then you need to be explicit about
the functionality you are dropping so that the list can decide if that
simplicty/functionality trade off is the right thing. The way to
proceed
here is to pick a permission you don't like, go section 5, see where
it's used and see if you can live without the granularity/functionality
that permission is providing. Then you need to explain that to the
list.
To help a bit, I have included a previous mail where I outlined the
functionality each permission provides and includes a proposal to drop
two of the permissions ("t" and "p") with an explanation of why I think
that
would be acceptable.
Rob.
> 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
>