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

[Howard Chu]

> Date: Mon, 19 Feb 2007 14:08:16 -0800
> From: Pete Rowley <prowley at redhat.com>

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