[Fedora-directory-devel] Attribute to determine allowed write attributes?

[Pierangelo Masarati]

Andrew Bartlett wrote:
> On Wed, 2006-11-01 at 07:05 -0700, Richard Megginson wrote:
>   
>> Andrew Bartlett wrote:
>>     
>>> On Tue, 2006-10-31 at 21:05 -0700, David Boreham wrote:
>>>   
>>>       
>>>> Andrew Bartlett wrote:
>>>>
>>>>     
>>>>         
>>>>> Does anybody have any pointers to an existing feature request like this,
>>>>> or should I file one in Bugzilla?
>>>>>  
>>>>>
>>>>>       
>>>>>           
>>>> This is what is implemented :
>>>>
>>>> http://www.redhat.com/docs/manuals/dir-server/ag/7.1/acl.html#1216899
>>>>     
>>>>         
>>> That has:
>>>
>>>   
>>>       
>>>> Information is not given for attributes in an entry that do not have a
>>>> value; for example, if the userPassword value is removed, then a
>>>> future effective rights search on the entry above would not return any
>>>> effective rights for userPassword, even though self-write and
>>>> self-delete rights could be allowed. Likewise, if the street attribute
>>>> were added with read, compare, and search rights, then street: rsc
>>>> would appear in the attributeLevelRights results.
>>>>     
>>>>         
>>> I need information on unknown attributes, so that MMC can show them as
>>> valid, writable fields (not greyed out).  My preferred format is a list
>>> of writable fields, as permitted by the current schema for that entry.
>>>   
>>>       
>> This could be useful in any general purpose GUI app, to have the ability 
>> to perform one query and get back a list of
>> 1) regular attributes available according to the schema
>> 2) operational attributes - writable vs. read-only
>> 3) virtual attributes - writable vs. read-only
>>
>> I would like to support the openldap "+" special attribute which 
>> retrieves all operational attributes, and I would also like to support 
>> the Sun DS real and virtual attrs controls.
>>
>> Andrew, I think it would be beneficial to me if you could post an 
>> example ldapsearch and an example return entry in LDIF.
>>     
>
> Using Samba's ldbsearch:
>
> bin/ldbsearch -H ldap://win2k3dc.win2k3.abartlet.net cn=administrator
> allowedAttributes allowedAttributesEffective allowedClasses
> AllowedClassesEffective -Uadministrator%penguin
>   
What's the -U for?  My guess is -U<user>%<cred>, is it correct?
> allowedAttributesEffective: adminDisplayName
>   
What identity does the "Effective" refer to?  That of the client 
performing the request?  How would this deal with ACL that depend on the 
value of the data?  How would this deal with ACLs that do not just 
depend on the object and on the client's identity?

Moreover, I believe this type of operation should be itself protected by 
ACLs, i.e. implementations should be able to restrict identities that 
can get this info.  With an ACL model that accounts for attribute values 
(like any serious implementation should provide), the list itself could 
be incomplete if access to specific values of allowedAttributes or 
allowedAttributesEffective is itself restricted.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati at sys-net.it
------------------------------------------