[proof of concept] libwbclient.so

[simo]

On Mon, 2007-09-03 at 07:11 -0500, Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> simo wrote:
> 
> > On my side I was thinking of building a 3 pipes
> > based approach. One pipe just for pam stuff, one for nss, and
> > one for winbindd specific related stuff. The idea is to keep
> > the first 2 _very_ simple and stable in time and make
> > them mimic closely the pam/nss API while the third can
> > change much more in time.
> 
> I'm pretty solidly opposed to this idea.  The API should be
> just that.  An API.  The fact that you can build PAM and
> NSS modules on top of it is of little consequence.

One problem I see is: why do we need to expose so much that we are at a
point where we need an API ?
For instance, I don't fully understand why we transport so much
information on the other side of the pipe and don't do most of the work
in winbindd.

Take the require-member-of thing.
Why do we need to resolve the member in the pam client? Why can't we
just send the string we got from from the pam config  and let winbindd
resolve it without adding another gratuitous round trip just to retrive
a list of SIDs? We do not need SIDs in pam for any reasons.
And actually re-reading the code is even worst, it is not just an
additional round-trip, it is one round-trip for every single group we
list in that directive ...

Why do we ever need to understand SIDs on the pam side anyway?

> > The reason why I am thinking about 2/3 pipes is 
> > because I would like to generalize the code so that
> > winbindd becomes just one of the components of a bigger
> > daemon which will provide services for the FreeIPA server as
> > well as legacy LDAP and/or Kerberos and even, eventually. 
> > NIS servers. The splitting of the PAM/NSS pipes will
> > make it possible to have completely separate PAM/NSS
> > modules that do not change much in time and provide
> > just the PAM/NSS interfaces. Also having a separate
> > pipe for other function may let us introduce a way to
> > authenticate requests so that we can provide a richer API
> > not only to fetch generic information but eventually
> > to set parameters and to retrieve privileged information.
> 
> This is too vague a description for me.  For example, by
> providing any API, we are already committing ourselves to a
> stable library interface that can be used by other developers.

True, but also to semantics I can't use for any other "backend",
name_to_sid make no sense when I am talking to a freeipa server.

> So any discussion about unchanged NSS/PAM interfaces doesn't
> make a lot of sense.  All your server daemon needs do is
> to link against the winbindd client DSO.

Except that doing this way I am on the wrong side of the fence.
My daemon is like winbindd it is just that I need to talk with other
things then just windows/samba servers. That's why I'd like to be able
to stay on the winbindd side and reuse, if at all possible, caching and
offline capabilities.

> And having a single pipe (or the two we have now) does not
> prevent introducing authentication mechanisms.  Particularly
> on Linux and other platforms that support the SO_PEERCRED
> socket options.  But there are some other threee way
> handshake protocols that can also be used for authentication
> all without introducing additional unix domain sockets.

True, even if relying on SO_PEERCRED is not portable. I am not too
attached to the multiple pipes idea I just thought that a clean
separation between what PAM/NSS, which are standard interfaces, need and
what a generic winbindd client needs may have been beneficial (and would
also keep the PAM/NSS socket interface much more simple).
I still don't get why we try to bring so much on the other side, when
all we need is to do auth/pwdchange or return passwd/group entries.
Why don't we do all the elaboration on the winbindd side?
Is there a technical reason?

> > The thing I would really be interested in, is providing 
> > a unified way, through a generic mechanism that can work
> > for any backend, to do caching and offline mode, possibly
> > also server/site affinity. Also I am interested in a
> > more generic mapping interface.
> 
> Winbind itself provides the caching and offline capabilities.
> I don't believe that making Winbind more generic or complex
> that is has to be do do its job it a good idea.

Yeah, I feared I'd find opposition like this :/

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org