This is a feature that exists in OpenLDAP (but has no RFC that I am aware of). Heimdal uses this feature exclusively for its directory interactions (making it incompatible with other LDAP directories), and Samba testing is often performed over unix domain sockets (a convenience for them). There are advantages: no TCP overhead for local connections, the ability to test for the OS level user credentials, and AFAIK, an unsniffable transport without additional requirements. On that last point, I welcome arguments to the contrary. 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. I've added LDAPI auto authentication / bind, which basically means that if you access the DS over LDAPI it will trust the OS level auth and automatically bind you at connection open (i.e. the server won't wait for an explicit bind). There are several options to this: 1. You can turn auto binding on or off 2. You can specify a dn that root should be bound as (e.g. directory manager, or perhaps an admin account) 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. 4. In the event that the other methods are turned off, or do not result in bind credentials, you can specify that a DN be constructed for the bind DN and supply a suffix for the DN - this allows non-mapped entries to look sensible, you may use this feature to specifiy a suffix that works with existing access control for example. When auto binding is on, and option 4. is set, or option 2. is set and the unix user credentials match a single entry in the DIT, users are automatically bound at connection open and anonymous binds are impossible since an anonymous bind attempt is modified to the credentials used at connection open. Non-anonymous binds work as usual. This means that scripts and so on can be "dumb" and credentials need not be left lying around for snoopers, users on the local machine not be concerned with credentials either, and yet all connections can be subject to targetted access control. All configuration is dynamically observed except for the socket file location and the LDAPI switch itself - these require a server restart for the same reasons TCP port modification does - the socket must be created with root privilege prior to suing to its execution user. Cross platform code for OS level authentication is currently defined out (other than linux), I intend to enable that as testing for these platforms progresses. Diff: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148370&action=... Additional files: getsocketpeer.c: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148371 getsocketpeer.h: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148372 ------------------------------------------------------------------------ -- Fedora-directory-devel mailing list Fedora-directory-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-devel

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.

> 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?

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.

On Mon, 2007-02-19 at 14:08 -0800, Pete Rowley wrote: > This is a feature that exists in OpenLDAP (but has no RFC that I am aware of). > Heimdal uses this feature exclusively for its directory interactions (making it > incompatible with other LDAP directories), and Samba testing is often performed > over unix domain sockets (a convenience for them). There are advantages: no TCP > overhead for local connections, the ability to test for the OS level user > credentials, and AFAIK, an unsniffable transport without additional > requirements. On that last point, I welcome arguments to the contrary. > > 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. > How do I change this location? What are the configuration parameters? It seems to be: + fprintf(f, "nsslapd-ldapifilepath: %s/%s-%s.socket\n", cf->run_dir, PRODUCT_NAME, cf->servid); + fprintf(f, "nsslapd-ldapilisten: on\n"); + fprintf(f, "nsslapd-ldapiautobind: on\n"); But some clarification would be useful.