<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 7, 2014 at 12:25 PM, Jakub Hrozek <span dir="ltr">&lt;<a href="mailto:jhrozek@redhat.com" target="_blank">jhrozek@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Tue, Dec 17, 2013 at 03:28:45PM +0200, Noam Meltzer wrote:<br>
&gt; On 17 December 2013 11:55, Jakub Hrozek &lt;<a href="mailto:jhrozek@redhat.com">jhrozek@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Tue, Dec 17, 2013 at 07:40:29AM +0200, Noam Meltzer wrote:<br>
&gt; &gt; &gt; Hello sssd-developers,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Allow me to introduce myself and the suggested contribution to the SSSD<br>
&gt; &gt; &gt; project. PrimaryData Inc. is a startup company in the field of<br>
&gt; &gt; distributed<br>
&gt; &gt; &gt; NAS. As such, we would like to contribute to the SSSD project by<br>
&gt; &gt; developing<br>
&gt; &gt; &gt; support for rpc.idmapd.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Below is our proposed design for this new feature.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Best regards,<br>
&gt; &gt; &gt; Noam Meltzer<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; ---<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Hi Noam,<br>
&gt; &gt;<br>
&gt; &gt; thanks for this design, it&#39;s great to have outside contributions!<br>
&gt; &gt;<br>
&gt; &gt; &gt; *SSS NFS Client (rpc.idmapd plugin) - Design*<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; We named the client &quot;sss_nfs&quot; (althogh &quot;sss_idmap&quot; or &quot;idmap&quot; might have<br>
&gt; &gt; &gt; been better names, the term &quot;idmap&quot; is already occupied in the SSSD<br>
&gt; &gt; world).<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; How does this client work, is it a module that the rpc.idmapd dlopens()<br>
&gt; &gt; ?<br>
&gt; &gt;<br>
&gt;<br>
&gt; yes, dlopen() is used.<br>
&gt; in more details: once &quot;sss_nfs&quot; is specified as a &quot;Method&quot; in<br>
&gt; /etc/idmapd.conf the module /usr/lib64/libnfsidmap/sss_nfs.so will be<br>
&gt; dlopen()ed<br>
&gt; (the file paths are under the assumption of fedora19 x86_64)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; *rpc.idmapd - background*<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; rpc.idmapd runs on NFSv4 servers as a userspace daemon (part of<br>
&gt; &gt; nfs-utils).<br>
&gt; &gt; &gt; It&#39;s role is to assist knfsd by providing the following 6 mapping<br>
&gt; &gt; functions:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 1. (user) name to uid<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 2. (group) name to gid<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 3. uid to (user) name<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 4. gid to (group) name<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 5. principal (user) name to ids (uid + gid)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 6. principal (user) name to grouplist (groups which user are member of)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; rpc.idmapd provides API for developing plugins (loaded by dlopen(3))<br>
&gt; &gt; which<br>
&gt; &gt; &gt; implements the actual mapping process.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; * note: 5 + 6 are relevant only for kerberised NFSv4 servers. At the<br>
&gt; &gt; first<br>
&gt; &gt; &gt; stage we only purpose a design without kerberos support.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; * note2: On the kernel level, there&#39;s a caching mechanism for the<br>
&gt; &gt; responses<br>
&gt; &gt; &gt; from the userspace daemon.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; *SSSD - Responder*<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The functionality required from the Responder side is a subset of the<br>
&gt; &gt; &gt; functionality provided by existing NSS Responder&#39;s commands.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; As you can see below (on the client part of the design) - no changes are<br>
&gt; &gt; &gt; needed in the NSS Responder.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; *SSSD - NFS Client*<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; *Responder-Facing Interactions (existing NSS Responder commands)*<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; SSS_NSS_GETPWNAM - map (user) name to uid requests<br>
&gt; &gt; &gt; SSS_NSS_GETGRNAM - map (group) name to gid requests<br>
&gt; &gt; &gt; SSS_NSS_GETPWUID - map uid to (user) name requests<br>
&gt; &gt; &gt; SSS_NSS_GETGRGID - map gid to (group) name requests<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The request &amp; reply sent to &amp; from the responder is &quot;standard&quot; in terms<br>
&gt; &gt; of<br>
&gt; &gt; &gt; the NSS Responder.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The client only needs a portion of the reply. Only this portion will be<br>
&gt; &gt; &gt; extracted from the packet (i.e. uid/gid/user name/group name).<br>
&gt; &gt;<br>
&gt; &gt; Sure, this would work and as long as you see no performance issues, this<br>
&gt; &gt; approach is completely fine.<br>
&gt; &gt;<br>
&gt; &gt; But please note that especially getgr* calls can be quite expensive,<br>
&gt; &gt; especially when nesting is involved. The reason is that normally the<br>
&gt; &gt; getgr* calls also download all the group members, resolving the nesting<br>
&gt; &gt; in the process.<br>
&gt; &gt;<br>
&gt;<br>
&gt; This sounds problematic.<br>
&gt;<br>
&gt;<br>
&gt; &gt; But if you do want to optimize further (perhaps in the future), we could<br>
&gt; &gt; then add a new NSS call that would only download the group entry in<br>
&gt; &gt; order to retrieve the GID. I think the backend part of this change would<br>
&gt; &gt; be also usable for the PAC responder and we already talked about this<br>
&gt; &gt; change recently with Sumit.<br>
&gt; &gt;<br>
&gt; &gt; But for version 1.0 I agree we can just use the existing NSS calls. A<br>
&gt; &gt; future version of the client can switch to another NSS call later, we<br>
&gt; &gt; can do that safely.<br>
&gt; &gt;<br>
&gt;<br>
&gt; Ok. lets start that way. Though I believe that we&#39;ll provide the extra NSS<br>
&gt; call soon enough...<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; *Optimisation Techniques*<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The optimisation techniques used for the NSS client will be used here as<br>
&gt; &gt; &gt; well. i.e. Fast Cache (memcache) &amp; negative-cache.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; It will be possible for the user to disable Fast Cache from the<br>
&gt; &gt; &gt; configuration file. (see below)<br>
&gt; &gt;<br>
&gt; &gt; What problems do you envision with the Fast Cache? Or did yo mostly want<br>
&gt; &gt; to make sure kernel does its own caching and the SSSD stays out of the<br>
&gt; &gt; way?<br>
&gt; &gt;<br>
&gt;<br>
&gt; As you guessed, we mostly want to make sure that the kernel does its own<br>
&gt; caching and SSSD stays out the way. :-)<br>
&gt; But that depends on the specific usage pattern. For others Fast Cache might<br>
&gt; be useful.<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; *Configuration File*<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The configuration of the client will be part of rpc.idmap config file<br>
&gt; &gt; &gt; (/etc/idmapd.conf).<br>
&gt; &gt;<br>
&gt; &gt; I think the plan sounds great in general!<br>
&gt; &gt;<br>
&gt;<br>
&gt; Thanks!<br>
<br>
</div></div>Hi Noam,<br>
<br>
since there were no other comments to the propsal, I think that means an<br>
ACK :-)<br></blockquote><div><br></div><div>Done.<br> <br></div><div><a href="https://fedorahosted.org/sssd/wiki/DesignDocs/rpc.idmapd%20plugin">https://fedorahosted.org/sssd/wiki/DesignDocs/rpc.idmapd%20plugin</a> <br></div>
</div><br><br clear="all"><br>-- <br><div dir="ltr"><table cellpadding="0" cellspacing="0"><tbody><tr><td>Noam Meltzer<br>Linux Software Engineer<br>PRIMARY DATA<br><br>P.O. Box 12650, Herzliya Pituach 4673300<br>9 Hamenofim St. Akerstein Towers, Tower A, 5th fl. Herzliya<br>
<br>Office: +972-77-8981888 | Fax: +972-3-7617140 | Mobile: +972-54-5873843<br><br>Email: <a href="mailto:noam@primarydata.com" target="_blank">noam@primarydata.com</a><br></td><td><span><label></label></span><br></td></tr>
</tbody></table></div>
</div></div>