Date: Mon, 19 Feb 2007 14:08:16 -0800 From: Pete Rowley <prowley@xxxxxxxxxx>
This is a feature that exists in OpenLDAP (but has no RFC that I am aware of).
I don't remember when/where this feature originated. Checking CVS I see that Luke Howard did the initial commit, 2000-01-02. I'd guess it was part of his early work on XAD. Originally we didn't use getpeereid, and just relied on socket permissions for access control. We added getpeereid in 2002, first on Linux and then Solaris and other platforms followed.
Heimdal uses this feature exclusively for its directory interactions (making it incompatible with other LDAP directories),
Luke also wrote that part of Heimdal, no surprise there... > 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.
It's possible, if you have privileges to insert kernel modules. But I think that's for someone else to worry about, not in scope here. (I.e., if you have someone malicious who can do that, you've already lost the machine.)
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:
I'd be a little concerned about this "auto bind". In OpenLDAP the credentials are only used if a SASL/EXTERNAL Bind is performed. In general I think it's poor policy to do something "magic" without a user actually requesting it. Especially where security is involved. Granted, a user could explicitly perform a Bind if they need to override the auto bind, but that's not the point. In typical LDAP use a session is anonymous until an explicit Bind has succeeded. IMO this behavior should be true regardless of the type of URL being used. E.g., with OpenLDAP right now, we can interchange ldap://, ldaps://, and ldapi:// URLs at will and apps see consistent behavior.
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.
As above, changing the semantics of anonymous Bind is a bad idea.
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=diff Additional files: getsocketpeer.c: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148371
As noted in OpenLDAP's implementation, using MSG_PEEK will fail on AIX. But I guess you can worry about that when you actually have the code base ported to AIX... You might consider using the same API/name as OpenLDAP does, for source code compatibility, even though this isn't a function apps need to call themselves. (I.e., I can't think of a need for it at the moment, but one may spring up down the road.)
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
