>I've finished the first cut at adding support for "access control
info" (aci)
>attributes to any object.

I look forward to review your ITS submission (hint). From your
description, it sounds quite useful. Here are a few comments.

OK, I'll do another round of improvements and make a submission in a
few days. So far the changes are limited to 4 files (about 95% in
acl.c). It should slip in pretty easily.

> your schema needs to be changed to ALLOW attributes of type "aci".
> I did this in my setup via the slapd.oc.conf file, and just added
> the aci attribute to a few object classes (person, groupOfNames, etc.).

Don't do that! Instead add an auxilary objectclass

objectclass aciobject
requires
objectclass
allows
aci

"Yah, what he said."

>The format of an aci attribute is taken from
>"draft-ietf-ldapext-acl-model-03.txt".

But I assume you have maintained our existing access semantics
and not:
5.2.1.1:
Each of the LDAP access rights are discrete. One
permission does not imply another permission.

Eventually we probably should implement discrete rights (behind
an #ifdef or config directive)... but that's project for another
day.

Already done both ways, with a #if to choose between the two. Right
now it's compiled (on my test server) with discrete rights, due in
large part because of 5.2.1.1 and also S13 in draft-ietf-ldapext-
acl-reqts-02.txt. It's a simple difference, really. Just <= instead
of &.

Personally, I prefer discrete rights, especially since you can
emulate right "levels" using a discrete rights implementation, but
not the other way around. It's nice to be able to set access to
attr=userPassword by self write-compare-not-read and such.

I encourage you to provide feedback to the authors of the I-D and/or
to the IETF LDAPext WG.

Note also that there some permissions apply to attributes,
some to entries, and some to the object to which the directory
entry points.

OpenLDAP, of course, has has one set of permissions to which
it applies to attributes, the "entry", and "children". Though
you could map some of the draft perms into our model, some
would require modification of the model. However, some items
do not fit into our existing model.

Example, the draft has "add" entry under this entry, "delete"
this entry, and "edit" this entry's DN. Our existing model
allows for an entry to be added, deleted, or dn edited only
if one has "write" permissions the parent's "children".
Our model is similiar to POSIX filesystem semantics for adding,
removing, and renaming a subdirectory which I find much cleaner.

This relates to the problem of getting entries from the backend. I
think being able to get an Entry directly from the backend would make
room for lots of improvements, in general.

Also, we have a perm "auth" which doesn't map well into the
semantics of the draft. However, I believe it wise to support
"auth" perms in ACIs.

Implemented, but commented out so it's there for later.

Because of these differences in semantics, I recommend we do
NOT use "aci" as the name of the attribute type to hold the
information. I suggest we use "acinfo" or "olaci" or such
(Or maybe VendorACI). Suggest we use a #define to allow
us to easily change it.

Wouldn't it be better just to use our own OID? The semantics are not
different from the draft, it's just that the draft leaves room for
interpretation (in some cases intentionally, like for "deny"). In
other words, there is no case where I'm saying "the draft is wrong,
I'm doing this a different way." There are only cases where I'm
saying "the draft does not specify what to do, so I'm doing it this
way." (Ummm, other than the discrete rights issue.) There is always
the chance that if/when the draft gets more specific, it will
contradict the implementation. But won't the OID make the
distinction? I'm just asking, I have no idea about the sanctioned
way to handle this.

And in any case, it might be better to at least start by using
something other than "aci" as the attribute type, as you suggest.
I'll change it to "olaci".