On Tue, Jan 28, 2014 at 4:10 PM, Simo Sorce <ssorce@redhat.com> wrote:
----- Original Message -----
> On Sun, Jan 26, 2014 at 9:36 PM, Simo Sorce < simo@redhat.com > wrote:

> > I think we should have a conversation with them because this code could
> > be also contributed directly to linux-nfs instead of sssd as it is now.

> That was my initial intention too, but after reading looking into the sssd
> source code and the various clients it provides, it felt more appropriate to
> make this plugin part of the sssd project.
> However, for that we'll need to have public API to access sssd. At the
> moment, I only see "sss_nss_idmap.h", "sss_idmap.h" & "ipa_hbac.h" publicly
> exported. Am I missing something here?

Well,
technically getpw[nam|uid] and getgr[nam|gid] will give you access to the same
data you are now pulling from sssd, or you can call the sssd client functions
directly, if you are so inclined, by dlopening() the libnss_sss.so library and
using the same standard interface glibc uses,
eg: _nss_sss_getpwnam_r(); _nss_sss_getpwuid_r(); .. etc...

Calling getpw[nam|uid] and getgr[nam|gid] will go through NSS which misses the point of having a dedicated plugin (and there's already an NSS plugin for rpc.idmap).
Using dlopen() and calling _nss_sss_getpwnam_r() sound too much like a hack.
So I think we need sssd to export an official API if we're going in that direction.


--
Noam Meltzer
Linux Software Engineer
PRIMARY DATA

P.O. Box 12650, Herzliya Pituach 4673300
9 Hamenofim St. Akerstein Towers, Tower A, 5th fl. Herzliya

Office: +972-77-8981888 | Fax: +972-3-7617140 | Mobile: +972-54-5873843

Email: noam@primarydata.com