[Fedora-directory-devel] Please Review: Add LDAPI (LDAP over unix domain sockets)

[Pete Rowley]

John Dennis wrote:
> On Mon, 2007-02-19 at 14:08 -0800, Pete Rowley wrote:
>   
>> The socket file is created as var/run/fedora-ds/slapd-<instance>.socket by
>> default, but this can be modified in configuration. I'm actually not sure where
>> the best place to put this is since access control along the path to the socket
>> matters. The socket itself is chmodded to give rw to owner, groups, and other by
>> the server upon creation.
>>     
>
> /var/run is the correct ancestor in the directory hierarchy. According
> to section 5 of FHS "System programs that maintain transient UNIX-domain
> sockets must place them in this directory [/var/run]". The fact it is
> also segregated into a subdirectory hierarchy by component name is also
> encouraged by FHS.
>
>   
OK, that's good.
>> 3. You can specify that the user maps to an existing entry via admin specified
>> attributes - which are probably going to be uidNumber and gidNumber (the
>> default) - root can be bound this way too, and this method takes precedence over 2.
>>     
>
> uid is appropriate, I am less certain gid is an appropriate attribute to
> be considered during a bind. Correct me if I'm wrong, but group
> membership is not considered in any of the other bind mechanisms.
Certainly access control can be set up to deny/allow the ability to bind 
based on group membership.
>  Isn't
> bind essentially "authentication" for which the uid in this constrained
> case of OS certified credentials would be sufficient to assert
> authentication?
In most cases I think the answer is yes.
>  OS group membership is a form of OS "authorization"
> which is not part of the LDAP bind authentication. The directory
> maintains it's own notion of group membership once the bind operation
> succeeds in authenticating the user thus establishing the user's group
> membership.
>   
Yes I understand and I agree. Note that the administrator may configure 
a single attribute (uid), so where a one to one mapping is required this 
will suffice. Here's the rationale for gid:

This is partially a conflation of OS authentication and LDAP 
authentication, with autobind the server is trusting the OS level 
authentication, but adding a requirement for its own authentication 
purposes for this bind method  - the gid - remember, this is just a 
mapping, a way to find the right unique entry in LDAP.  This could be 
useful when you _do_ have multiple users mapped to the same uidNumber, 
but differ by gidNumber.  Think of the root example:  computer admin, 
department admin, domain admin - all map to uidNumber: 0 for the 
purposes of OS authentication, but for LDAP authentication these are 
very different identities that may be subject to differing access 
control e.g. computer admin gets to administer local computers, 
department admin gets to administer their department computers etc. Of 
course, there are other ways to achieve that, but when a deployment 
works that way already, supporting the capability is no bad thing.

Hopefully, that makes sense.

-- 
Pete

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20070220/96c1e21e/attachment.bin>