[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ACI developmental status

Howard Chu writes:
>Hallvard B Furuseth wrote:
>> For that matter, what if you want to allow users write access to the
>> access controls for their own entries?
> From a usability standpoint I agree with you. I worked on file servers
> before coming to OpenLDAP and that has always colored my view of how the
> directory should work. (I.e., why isn't it just like a filesystem? E.g.
> back-bdb/ldbm - why no support for tree renames (back-hdb), what about
> mount points (back-ldap, backglue), what about hard links...) But this
> suggestion of yours would be an enterprise security manager's nightmare.
> The potential for abuse is unbounded.

Sorry, what I meant was "write access to the ACIs in their own entries".
Then slapd.conf decides the potential for abuse.  For example,

 access to attrs=userPassword  by self ssf=128 =wx  by ssf=128 auth
 # 'children' statement not really necessary in this example, but:
 access to attrs=children  by * read
 access to <people> attrs=<wide open attrs>  by self write  by aci write
 access to <people>  by self write  by aci read
 access to *  by * read

Now users can't open up their passwords, and can only make selected
attributes writeable by others - since as far as I tell 'by aci read'
will never allow more than read access, no matter what the aci attribute
says.  Nor can they accidenally lose their own access to their entries.

> I think this vulnerability could
> be lessened somewhat by borrowing another filesystem notion - per-user
> storage quotas. Then at least, if a user carelessly leaves themselves
> wide open, you can limit the damage that can be done.