Re: Access Rights in SLAPD.CONF

[patl@phoenix.volant.org]

> 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?

The most obvious use is password checking without exposing the (encrypted)
passwords.

> 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"?

I believe that ompare is roughly equivalent to allowing exact match
searches while denying substring, inequality, presence, etc.

>                                                        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!). 

But you don't necessarily search on an exact match against a complete
literal value.  In fact, you can search on the presence or absence of
an attribute without knowing anything at all about the value.

An attempt to circumvent 'compare' access by doing exact match searches
is basicly a brute force search of the value space.  In most cases
highly impractical.

> 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.

Why shouldn't you be able to see your own (encrypted) password?
Presumably, you already know the (unencrypted) value, since you
were able to use it to bind.

And if my users are stupid enough to -want- to display their passwords
on-screen, there's not much I can do to stop them.  The problem here
is really generic LDAP browsers that don't know enough about the schema
in use to know that they shouldn't display a userPassword even if the
server returns it.

> 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).

This could easily be an NDS restriction.  If the LDAP<->NDS gateway
can't retrieve the password, it can't pass it on.  It would be
interesting to discover whether it supports all of the LDAP search
modes on the password field...  (Of course, it would only return
your own entry, since you presumably only have 'compare' access
against the others.) 


-Pat