[proof of concept] libwbclient.so

[simo]

On Sun, 2007-09-02 at 18:45 +0200, Stefan (metze) Metzmacher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Jerry,
> 
> > New files and patch posted to
> >   http://samba.org/~jerry/src/libwbclient/
> > 
> > This includes the SID<->String conversion utilities.  Also need to
> > finish wbcErrorString() to the user-friendly error descriptions.
> 
> I'm currently working on a NDR based winbind protocol...
> 
> I think it would be very nice if we could define the protocol as IDL
> and let pidl create the header file (which you wrote by hand).
> 
> Then I'd just need to change the transport layer to NDR but the
> logical interface would match the one of the handwritten wrapper
> arround the old protocol.
> 
> What do you think about this?


I have been following the winbindd protocol proposal, as I myself am
thinking as well on how to reuse part of the winbindd infrastructure and
experience to build a more generic service to be used inside the
FreeIPA[1] project. I came to the conclusion I don't like the current
way winbindd uses the pipes (the gigantic structure we pass is too
difficult to use reliably).
So I am very interested in any proposal.

On my side I was thinking of building a 2/3 pipes based approach.
One pipe just for PAM and for NSS (or may be one each), and one for
winbindd specific related stuff. The idea is to keep the first (PAM/NSS)
_very_ simple and stable in time and make them mimic closely the PAM/NSS
API while the third can change much more and be independent.

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 may not be necessarily a good solution, a single pipe may be good
as well, but the problem I see with a single pipe is that for
non-winbindd backends I would have a lot of calls that can't simply be
fulfilled, and maybe others that are similar but do not match exactly
the semantics of winbindd.

Splitting these out in different pipes, I realize may be worst then
trying to fit all together though, so I'd like to know if other has
better solution that may accomodate my needs as well.

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.

Simo.


[1] http://www.freeipa.org/

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