Re: Access Rights in SLAPD.CONF

["Keith Keller" <kkeller@dspeed.net>]

On 30 Apr, David J N Begley wrote:

> What's actually the purpose of "by * compare"?  I mean, I'm using:
> 
>   defaultaccess  read
>   access         to attr=userpassword
>                  by self write
>                  by * none
> 
> and authenticated binds to the directory still work without any problems.

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.
It seems like a vicious circle, since to gain access to the 
userpassword, the user needs to authenticate, but in order to
authenticate, the user needs access to the userpassword.  Presumably
(?) the server knows to do a compare only until the compare actually
matches, then knows to bind as that user and allow access to
the userpassword.  But that's all pure speculation.

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

On a side note, are there any plans for encrypted password
support in OpenLDAP?  I feel this is important for the sanity
of the end users--if their password is stored as plain text,
then an administrator can go read it and then do evil things
in their name.  Granted, the admin can change the password
and do evil things anyway, but then at least theoretically
there's some sort of record that there was a password change.
And again, the current configuration does not allow passwords
to be write-only, so giving an admin write (which s/he must
have) also gives read to the userpassword (which s/he should
not have).

-- Keith
kkeller@dspeed.net