Re: Access Rights in SLAPD.CONF

[David J N Begley <david@avarice.nepean.uws.edu.au>]

On Fri, 30 Apr 1999, Keith Keller wrote:

> On 30 Apr, David J N Begley wrote:
> 
> > What's actually the purpose of "by * compare"?  I mean, I'm using:
[...]
> This is just a guess, but since authentication is done in order,
> if a user binds (or attempts to bind) as him/herself, then s/he
> falls under the "by self" scheme, and thus can bind successfully.

Which brings me back to my original question - what's the purpose of "by *
compare"?  I mean, under what example circumstances might it be needed?

> > Unfortunately the UMich SLAPD Admin guide isn't too clear on distinguishing
> > the differences between "none", "compare", "search", "read" and "write"
> > (beyond the bleedin' obvious which no doubt leaves everything open to
> > interpretation - not good for ACLs).
> 
> Dunno.  I feel like the definitions are clear enough, but not

Well as I say, "beyond the bleedin' obvious" - but that's simply not good
enough when writing access controls to enforce a security policy;  you end up
with "assumptions" about what will and will not get through.  When writing
ACLs, you need to know for *certain* what will and will not get through.

We know from the documentation that the (descending) precedence order is:

- write
- read
- search
- compare
- none

and that permitting a higher precedence access automatically includes the
lower access methods.

Now, attributes like "write", "read" and "none" are pretty obvious, but what's
the difference between "search" and "compare"?  What if I grant "search"
access but don't want "read" access - if someone can search on an exact match
for a particular attribute then surely that means they can "read" it (because
they already know what the contents of the attribute are!).

Just seems like an incomplete ACL scheme to me... (either that, or the
incomplete UMich docs - which takes me back to where I started).

> separate enough.  For example, giving "write" also gives "read",
> which gives "search", which gives "compare".  What if I want
> my users *only* to write and compare, not read?  This makes
> lots of sense with passwords, where you wouldn't want your users
> to be able to display their password on screen, but you still
> want them to be able to change passwords.

Exactly!  This is similar to how Novell's NLDAP front-end to NDS works (as a
user I can set my own password and I can authenticate using my password, but I
still can't retrieve the userPassword attribute at all).

> On a side note, are there any plans for encrypted password
> support in OpenLDAP?

It's there already (RFC 2307-style).

Cheers..


dave