[Review Request] libwbclient-sssd

[Sumit Bose]

On Thu, Jun 19, 2014 at 11:17:57AM +0200, Volker Lendecke wrote:
> On Wed, Jun 18, 2014 at 09:51:28AM -0700, Jeremy Allison wrote:
> > On Wed, Jun 18, 2014 at 05:41:55PM +0200, Volker Lendecke wrote:
> > > On Wed, Jun 18, 2014 at 05:25:59PM +0200, Michael Adam wrote:
> > > > I think that it is conceptually wrong to have the sssd wbclient
> > > > library not with the sssd server (where it belongs) but in samba code.
> > > 
> > > Looking back at why Gerald did libwbclient, I have to agree
> > > with Michael. There are other libwbclient implementations
> > > out there, living together with their respective server
> > > implementations. What makes sssd different in this regard?
> > 
> > I think it would be better for Samba long term to have
> > a closer and more co-operative relationship with sssd.
> > 
> > The other libwbclient implementations are closed source,
> > sssd is a natural partner for Samba.
> > 
> > Just my 2 cents.
> 
> Looking at the actual implementation it becomes visible that
> the proposal can be made much more general: It is a generic
> implementation of libwbclient on top of nsswitch:
> 
> +static bool open_libnss_sss(void)
> +{
> +       ctx = calloc(1, sizeof(struct nss_ops_ctx));
> +       if (ctx == NULL) {
> +               return false;
> +       }
> +
> +       ctx->dl_handle = dlopen("libnss_sss.so.2", RTLD_NOW);
> +       if (ctx->dl_handle == NULL) {
> +               goto fail;
> +       }
> +
> +       ctx->getpwnam_r = dlsym(ctx->dl_handle, "_nss_sss_getpwnam_r");
> +       if (ctx->getpwnam_r == NULL) {
> +               goto fail;
> +       }
> 
> ... and so on. You could easily implement the same idea on
> top of libnss_winbind.
> 
> What about the following, different approach:
> 
> Implement the server side of the nsswitch and idmap related sssd protocol
> calls in winbind. Then we could implement the client side of those in
> a unified libwbclient_winbind_and_sssd an could also freely exchange
> libnss_sss and libnss_winbind or potentially get rid of one of them. This
> way the sssd protocol could become the reference for implementing nss
> semantics over a local transport. Then we only have to convince the
> nss_ldap people to also implement this and we're done, right? :-)

I think this would work for the pure NSS use case because here the
interface is synchronous. And iirc we already agreed that this is a good
idea and we already have a ticket for SSSD to release the related
components separately https://fedorahosted.org/sssd/ticket/2240.

But for the more important and more demanding samba use case an
asynchronous interface would be the better choice.  This includes the
idmapping calls but others like e.g. informations about trusted domains
(which can be provider by SSSD as well, but I haven't implemented the
related calls in this version of libwinbind_sssd because SSSD will make
this data available via a different provider than the NSS provider).

bye,
Sumit

> 
> Volker
> 
> -- 
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9
> AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> http://www.sernet.de, mailto:kontakt at sernet.de