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

Re: ldapACI permissions



Our comments are embedded in the copy of the email.

: Rick/Ryan,
: 
: 
: Page 12:
: 
: TECHNICAL:
: 
:                  e    EditDN   Edit an entry's DN
:                  b    BrowseDN Browse an entry's DN
: 
: How is EditDN permission different from Write permission on the naming
: attribute?  How is BrowseDN permission different from Search permission
: on the naming attribute?  Can I have EditDN permission on the entry
: without explicit Write permission on the naming attribute of the
: entry?  What would it mean?
: 
: (EJS) EditDN and BrowseDN work at the entry level (DN) and equate to 
: permissions
: to modify/access the DN for ldapmodifyDN/ldapmodifyRDN/ldapSearch operations.
: Write works at the attribute level on attributes.

But now you have two different permissions that apply to the same
data.  What is the precedence between them?  How should the server
interpret the case where there is EditDN permission on the entry
without explicit Write permission on the naming attribute of the
entry?  "deny" is the default when there is no ACI, and "deny" takes
precedence over "grant".  Would this mean that the DN cannot be
changed even though EditDN is granted?

: And do we really need both Search and Compare permissions?
: (EJS)  Yes, search and compare and 2 different operations.

OK.  The difference is so slight I had thought we might be able to use
one permission to cover both.

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

: Ellen

Rick and Ryan