Re: [Fedora-directory-devel] Please Review: Add LDAPI (LDAP over unix domain sockets)
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
Attachments:
- smime.p7s (application/x-pkcs7-signature — 3.2 KB)