Re: (ITS#3849) support for posixGroup use in ACLs

[ando@sys-net.it]

jtownsend@opendarwin.org wrote:

>On Jul 8, 2005, at 10:17 AM, Kurt D. Zeilenga wrote:
>
>  
>
>>I think addition of this feature would lead to confusion as
>>the implemented semantics are not actually consistent with
>>those specified for posixGroup.   First, there is no requirement
>>to name accounts using the uid attribute or that it be the
>>only naming attribute.  The code assumes its the one and only
>>naming attribute for accounts.  Second, an account can belong to
>>a posixGroup without its uid value being listed as a memberUid
>>of the posixGroup.  That is, an account can be member due to
>>having the same gidNumber value as the posixGroup.
>>
>>I also dislike that this patch opens all member attributes
>>to those of IA5 string syntax.  Few attributes of IA5 string
>>syntax are used to identify group members (or like semantics).
>>
>>I also note that ACL sets can be used today to provide more
>>complete posix group semantics.
>>
>>However, my main concern is that this extension is specific
>>to a particular user application (POSIX information services)
>>and, hence, not generally useful.  Hence, I do not believe this
>>new feature should be incorporated into OpenLDAP Software.
>>
>>    
>>
>
>Fair enough.
>
>I guess we'll just keep that as a modification in the Mac OS X  
>version of OpenLDAP for now then.
>
>We have a need to allow a posixGroup to be used by OpenLDAP and right  
>now the administrative tools don't populate DNs but rather  
>shortnames. Maybe this is something that could be implemented through  
>a plug-in which kept a list of uniqueMember values in sync with the  
>list of memberUid values? Alternately, is there any way to extend the  
>ACL system through plug-ins?
>  
>

That's exactly what I was about to suggest.  There's two separate 
mechanisms.  You could use the "dynacl" mech (see 
servers/slapd/{acl,aclparse}.c for guidelines; ACIs have been 
re-engineered following this approach), or overlays (where you're 
supposed to only provide the bi_access_allowed member of the BackendInfo 
structure).  I think in your case the former approach is favorable, 
because you wouldn't need the rest of the overlay infrastructure to be 
in place.

Unfortunately there's no developers' guide about implementing a new 
"dynacl", but its use should be straightforward: first of all, you need 
to write a module that contains an init_module() function that calls 
slap_dynacl_register() to register your custom ACL infrastructure.  
Within thsi infrastructure you essentially need to provide calls to your 
custom parse and mask functions; unparse, destroy and so can be 
optional.  The name could be something like "posixgroup"; that will be 
the name you'll use to identify your clause in slapd.conf, something 
like "dynacl/posixgroup.exact=<DN>".

p.


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497