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.
Certainly access control can be set up to deny/allow the ability to bind based on group membership.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.
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.
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: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.
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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
