On 17 December 2013 11:55, Jakub Hrozek <jhrozek(a)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
> NAS. As such, we would like to contribute to the SSSD project by
> support for rpc.idmapd.
> Below is our proposed design for this new feature.
> Best regards,
> Noam Meltzer
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
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
(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
> It's role is to assist knfsd by providing the following 6 mapping
> 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))
> implements the actual mapping process.
> * note: 5 + 6 are relevant only for kerberised NFSv4 servers. At the
> stage we only purpose a design without kerberos support.
> * note2: On the kernel level, there's a caching mechanism for the
> 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
> 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
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
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
> *Configuration File*
> The configuration of the client will be part of rpc.idmap config file
I think the plan sounds great in general!
*Linux Software Engineer*
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