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