[Review Request] libwbclient-sssd

[Simo]

On Tue, 2014-06-24 at 16:16 +0200, Volker Lendecke wrote:
> On Tue, Jun 24, 2014 at 04:08:29PM +0200, Jakub Hrozek wrote:
> > On Tue, 2014-06-24 at 15:49 +0200, Sumit Bose wrote:
> > > On Tue, Jun 24, 2014 at 03:37:34PM +0200, Volker Lendecke wrote:
> > > > On Tue, Jun 24, 2014 at 03:00:32PM +0200, Jakub Hrozek wrote:
> > > > > On Tue, 2014-06-24 at 13:17 +0200, Volker Lendecke wrote:
> > > > > > > FYI for more complex queries the next SSSD release will have a new
> > > > > > > provider called InfoPipe which uses the D-Bus protocol. But I guess this
> > > > > > > is SSSD specific and will not have much overlaps with samba or winbind
> > > > > > > with respect to the protocol.
> > > > > > 
> > > > > > What additional information goes over this protocol?
> > > > > 
> > > > > See the design page:
> > > > > https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
> > > > > 
> > > > > tl;dr version is that only the basic POSIX set is allowed by default and
> > > > > the admin can configure what additional attributes are made public on
> > > > > the bus.
> > > > > 
> > > > > However, the user and group objects are not quite there yet. We hope to
> > > > > get them done completely during the next month or so for the SSSD-1.12.1
> > > > > release.
> > > > 
> > > > So this means the protocol that nss_sssd speaks right now is
> > > > a dead end and everything will go over dbus in the future? I
> > > 
> > > Nobody said that. There are no plans to change the protocols for the PAM
> > > and NSS clients.
> > > 
> > > bye,
> > > Sumit
> > > 
> > 
> > Yes, the D-Bus API is intended for applications that need to access more
> > data about the users SSSD serves than the NSS API provides. For instance
> > a desktop environments might read the preferred keyboard layout or some
> > user avatar using this interface.
> > 
> > But the standard NSS and PAM modules are here to stay.
> 
> Also over the current protocol, or will SSSD eventually
> decide to abstract that enough to slip in dbus under it? For
> Fedora it would make perfect sense to get rid of yet another
> custom protocol.

No, the protocol is not the problem. The problem is sneaking complex and
problematic libraries to resolve local nss/pam calls.

For example IIRC libdbus uses asserts on some failures, plus it does not
behave necessarily well should the application reinitialize the library
on it's own.

The whole point of the custom nature of the protocol and sssd nss/pam
libs is that they depend on nothing more than what glibc provides and
are extremely slim to reduce to the minimum the chance that the code
will segfault the application using it, as that is an extremely bad
thing to do.

Simo.