samba-technical@lists.samba.org
[Top] [All Lists]

Re: [proof of concept] libwbclient.so

Subject: Re: [proof of concept] libwbclient.so
From: "Gerald (Jerry) Carter"
Date: Mon, 03 Sep 2007 07:11:27 -0500
-----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.

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

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.

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





cheers, jerry
=====================================================================
Samba                                    ------- http://www.samba.org
Centeris                         -----------  http://www.centeris.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG2/nvIR7qMdg1EfYRAjSfAKDjE84ZjmtPMbed+gZqSN2QL4FhEwCg2DfQ
RzmgP5SOiWLNpGSUsT6zspI=
=UTi3
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>