[SSSD] rpc.idmapd plugin

Noam Meltzer noam at primarydata.com
Tue Dec 17 13:28:45 UTC 2013


On 17 December 2013 11:55, Jakub Hrozek <jhrozek at redhat.com> wrote:

> On Tue, Dec 17, 2013 at 07:40:29AM +0200, Noam Meltzer wrote:
> > Hello sssd-developers,
> >
> > Allow me to introduce myself and the suggested contribution to the SSSD
> > project. PrimaryData Inc. is a startup company in the field of
> distributed
> > NAS. As such, we would like to contribute to the SSSD project by
> developing
> > support for rpc.idmapd.
> >
> > Below is our proposed design for this new feature.
> >
> > Best regards,
> > Noam Meltzer
> >
> >
> >
> > ---
> >
>
> Hi Noam,
>
> thanks for this design, it's great to have outside contributions!
>
> > *SSS NFS Client (rpc.idmapd plugin) - Design*
> >
> > We named the client "sss_nfs" (althogh "sss_idmap" or "idmap" might have
> > been better names, the term "idmap" is already occupied in the SSSD
> world).
> >
>
> How does this client work, is it a module that the rpc.idmapd dlopens()
> ?
>

yes, dlopen() is used.
in more details: once "sss_nfs" is specified as a "Method" in
/etc/idmapd.conf the module /usr/lib64/libnfsidmap/sss_nfs.so will be
dlopen()ed
(the file paths are under the assumption of fedora19 x86_64)



> >
> > *rpc.idmapd - background*
> >
> > rpc.idmapd runs on NFSv4 servers as a userspace daemon (part of
> nfs-utils).
> > It's role is to assist knfsd by providing the following 6 mapping
> functions:
> >
> > 1. (user) name to uid
> >
> > 2. (group) name to gid
> >
> > 3. uid to (user) name
> >
> > 4. gid to (group) name
> >
> > 5. principal (user) name to ids (uid + gid)
> >
> > 6. principal (user) name to grouplist (groups which user are member of)
> >
> > rpc.idmapd provides API for developing plugins (loaded by dlopen(3))
> which
> > implements the actual mapping process.
> >
> > * note: 5 + 6 are relevant only for kerberised NFSv4 servers. At the
> first
> > stage we only purpose a design without kerberos support.
> >
> > * note2: On the kernel level, there's a caching mechanism for the
> responses
> > from the userspace daemon.
> >
> >
> > *SSSD - Responder*
> >
> > The functionality required from the Responder side is a subset of the
> > functionality provided by existing NSS Responder's commands.
> >
> > As you can see below (on the client part of the design) - no changes are
> > needed in the NSS Responder.
> >
> >
> > *SSSD - NFS Client*
> >
> >
> > *Responder-Facing Interactions (existing NSS Responder commands)*
> >
> > SSS_NSS_GETPWNAM - map (user) name to uid requests
> > SSS_NSS_GETGRNAM - map (group) name to gid requests
> > SSS_NSS_GETPWUID - map uid to (user) name requests
> > SSS_NSS_GETGRGID - map gid to (group) name requests
> >
> > The request & reply sent to & from the responder is "standard" in terms
> of
> > the NSS Responder.
> >
> > The client only needs a portion of the reply. Only this portion will be
> > extracted from the packet (i.e. uid/gid/user name/group name).
>
> Sure, this would work and as long as you see no performance issues, this
> approach is completely fine.
>
> But please note that especially getgr* calls can be quite expensive,
> especially when nesting is involved. The reason is that normally the
> getgr* calls also download all the group members, resolving the nesting
> in the process.
>

This sounds problematic.


> But if you do want to optimize further (perhaps in the future), we could
> then add a new NSS call that would only download the group entry in
> order to retrieve the GID. I think the backend part of this change would
> be also usable for the PAC responder and we already talked about this
> change recently with Sumit.
>
> But for version 1.0 I agree we can just use the existing NSS calls. A
> future version of the client can switch to another NSS call later, we
> can do that safely.
>

Ok. lets start that way. Though I believe that we'll provide the extra NSS
call soon enough...


>
> >
> >
> > *Optimisation Techniques*
> >
> > The optimisation techniques used for the NSS client will be used here as
> > well. i.e. Fast Cache (memcache) & negative-cache.
> >
> > It will be possible for the user to disable Fast Cache from the
> > configuration file. (see below)
>
> What problems do you envision with the Fast Cache? Or did yo mostly want
> to make sure kernel does its own caching and the SSSD stays out of the
> way?
>

As you guessed, we mostly want to make sure that the kernel does its own
caching and SSSD stays out the way. :-)
But that depends on the specific usage pattern. For others Fast Cache might
be useful.


>
> >
> >
> >
> > *Configuration File*
> >
> > The configuration of the client will be part of rpc.idmap config file
> > (/etc/idmapd.conf).
>
> I think the plan sounds great in general!
>

Thanks!


-- 

*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 at primarydata.com

 * <Slankry at PrimaryData.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20131217/8c2d4b6b/attachment.html>


More information about the sssd-devel mailing list