[Review Request] libwbclient-sssd
sbose at redhat.com
Fri May 16 14:13:37 MDT 2014
On Tue, May 13, 2014 at 01:02:47PM +1200, Andrew Bartlett wrote:
> On Fri, 2014-05-09 at 18:52 +0200, Sumit Bose wrote:
> > Hi,
> > I'm looking for review and comments on my patches in
> > http://fedorapeople.org/cgit/sbose/public_git/samba.git/log/ .
> > They add a replacement for libwbclient which talks to SSSD
> > (https://fedorahosted.org/sssd/) instead of winbindd. One of the
> > use-cases for this library is to run Samba on FreeIPA clients where the
> > FreeIPA domain already has a trust relationship to an AD forest.
> > Currently not all calls are implemented but it already works quite well.
> > I would prefer to maintain this library in the Samba source tree
> > instead e.g. in the SSSD tree. We already have a id-mapping plugin for
> > cifs-utils in the SSSD tree but here the plugin interface is very small
> > and I think chances are low that it will change any time soon.
> > libwbclient on the other hand is more complex and contains quite some
> > calls which are independent of the backend (e.g. memory management and
> > conversion utilities). I tired to extract this common code in some of
> > the patches so that it can be used by both libraries.
> > Please let me know if you think that those patches can be included in
> > the samba tree (and what I have to fix/change to make it happen) or if
> > you think it would be better to maintain it externally?
> > Btw, I will be available for discussion next week on SambaXP.
> The main concern I have is if that this will again tie us to the
> libwbclient ABI, at a time when we at least I am looking at better ways
> to communicate to and from winbindd.
> For example, libwbclient is not async, and in my area of concern, the
> wbcAuthenticateUserEx call is quite unfortunate in the amount of data
> that is lost (by converting to unix time) when both ends simply want the
> 'info3' structure.
> I was hoping as part of the winbindd merge to propose an improved async
> interface for smbd authentication against winbindd, for example. If we
> bypass libwbclient then that might break you.
I'm aware form following samba-technical and talking with Andreas and
Günther that a change to the winbindd interface is needed and might
happen quite soon.
One of the reasons to send the patch now is to let you and the others
who are thinking about a new interface know that there are other
providers who would like to offer services like id-mapping,
domain/forest discovery etc to samba so that the design can be done
Changing the interface won't break me because I would like to be an
active maintainer of the interface to SSSD. And if you are about to
change the interface to winbindd I would like to do the same for the
interface to SSSD so that you can get rid of the old interface once and
>From my point of view if would be nice to have a plugin interface
instead of a library to avoid struggling with version information,
library names etc. To make is async the interface can use
tevent_req-style requests with *_send() and *_recv() calls. But I'm not
an expert here when it comes to the special needs of samba with e.g
respect to performance and would like to leave the details in the
capable hands of you and the other members of the Samba team.
> I know this is much more a philosophical than a technical objection, and
> you would rightly ask 'why didn't you tell me before now', but this is
> the first I've heard of this.
> Now, that might mean we should just include this in Samba, and so ensure
> either winbindd and sssd can be contacted, over current or future
> versions of the library. I'm not sure, but I wanted to communicate my
> concerns here.
> I hope these thoughts are not too confusing,
No, totally clear. I hope I was able to show you that we are on the same
page and to lessen your concerns.
> Andrew Bartlett
> Andrew Bartlett
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba-technical