[proof of concept] libwbclient.so

Tue Sep 4 16:21:04 GMT 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simo,

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

Because "winbind use default domain" was such a great idea. :-)

Seriously, an API provides an application developer with
the tools needed to decide policy.  Placing all policy in
winbindd is inflexible and places undue burden on a service
central to the operating system.

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

Many things on the Unix side need to understand SID and to
be able to convert them to uids/gids.  Any cifs file system client
needs to be able to do this.  Any GUI app displaying security
descriptors on a remote share need to be able to do.  Even smbd
needs to be able to do this. A login manager that wants to display
a list of available domains (like a Windows client would do)
should be able to make an API call not system("wbinfo -m").

You and I have two main points of contention.  You want a PAM/NSS
specific API and more generic Winbind API.  IMO that is unnecessary
and a bad design.  Because of your design, you see pam_winbind
using on API and smbd using another.  My point is that there is
only one API provided by the winbind client library.  This single
library is used by pam_winbind and smbd.

As long as you continue to believe that there should be two
or three different libraries, then of course you will never
see why pam_winbind would need to be able deal with SIDs.

I believe that you are simply confusing policy and mechanism.

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

This still makes no sense to me.   Winbind is the LSA service
of Unix.  Your FreeIPA server should be built upon system
services.  Write your own daemon, link against libwbclient,
Write backends for your daemon and do whatever you want.

Winbind provides a service and should also provides the means
to programaticly access that service.  This is fundamental
any real AD desktop and server integration solution beyond
just PAM logins for ssh.

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

No.  I completely disagree.  Write your own daemon.  Write
your own caching service and your own offline capabilities.

Things that try to do everything very seldom do anything
well.  If you try to make Winbind a generic name service,
you will completely destroy any usefulness that it currently
provides as you needs are well beyond the scope of what Winbind
should be providing.

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

Please seen my comment about policy and mechanism and then
explain to me how our design is not combining the two into one.

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.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG3YXwIR7qMdg1EfYRAq5AAKCLBX05iGrM+QHawX5e1q/lbMmqmwCgoE3f
SKQESvt9A8OFaiUUwM5o00M=
=VPIo
-----END PGP SIGNATURE-----