Re: ldapACI permissions

[djbyrne@us.ibm.com]

My Comments preceded by < djb >


Thanks,

Debora Byrne
Manager Secure Way Directory Config / User Interface
INet: djbyrne@us.ibm.com
Phone: (512)838-1930 ( T/L 678 )


: >TECHNICAL: What's the interaction between "[entry]" and attributes: if
: >somebody has add permission for objects but is denied permissions for
: >certain attributes, what happens?
:
: (EJS) None.  [entry] applies to the permissions a/d/e/b.  [all] applies
to the
: permissions for attributes.  If a person has add permission, then he can
add
: an entry and its attributes to that place in the DIT.  The permissions
for the
: attributes he added as part of adding that entry are governed by the
access
: control attribute (ldapACI) that is added to that entry.

So inherited access rights on attributes don't apply when a new object
is being created; the only thing that applies is the permission to
create a new entry.  A person can write all attributes of a newly
created object even if inherited attribute rights say the person canNOT
write some of those attributes.  But as soon as the entry has been
created, the creating entity can not change any attribute unless
inherited rights permit it.  Also, the creating entity CAN create a new
ldapACI attribute as part of the new entry and thus override any
inherited rights.

Taken together, this means that entry level a/d rights mean you can
change anything in an entry since you can always delete, then re-add
with whatever attribute values you want.  This makes us nervous.

< djb > I agree with your analysis that having both delete and add
permission on the object essentially means that one could delete the
object, and re-add it, filling in attributes, and access control as it
liked.    If the concern is that users would circumvent the access control
checks by doing this sort of thing, I might suggest that an auditing
facility is needed for that directory.

Is the suggestion here that  when creating an entry, a user can only set
the values on those attributes to which he also has 'write' permission?
Does this also mean the user needs 'write/delete' permission on all
attributes which have values when he is deleting the entry?

While the draft maintains that the inheritance model is server dependant,
from our own experience, I'd suggest caution when restricting what can be
done at object creation time.  We did ( at one point ) consider an
inheritance system where setting access control on newly created objects
was controlled by parent inheritance. We ended up removing the feature
because our exploiters had great difficulty ensuring their applications
could install and use the directory. It required that everyone who could
install something needed to have an enormous amount of access to ensure
that they could instantiate the needed application objects.