[SSSD] [PATCH v2 0/5] NFSv4 rpc.idmapd plugin

Noam Meltzer tsnoam at gmail.com
Fri Jun 20 18:50:29 UTC 2014


On Fri, Jun 20, 2014 at 5:09 PM, Jakub Hrozek <jhrozek at redhat.com> wrote:

> On Tue, Mar 04, 2014 at 09:37:51AM +0200, Noam Meltzer wrote:
> > Hello sssd-devel & linux-nfs,
> >
> > This is v2 of the patch set. It is now sent to linux-nfs as weel,
> following
> > Steve Dickson request.
> >
> > The code in the next 5 patches implements the design document:
> > https://fedorahosted.org/sssd/wiki/DesignDocs/rpc.idmapd%20plugin
> >
> > The changes in the code (compared to v1) are following the review done in
> > sssd-devel.
> > I believe that there are still two items in dispute (no final verdict
> was given
> > in the sssd mailing list) but this new patch set will give a chance to
> have a
> > cleaner look on things.
>
> I have a couple of minor suggestions about the patches (mostly style
> issues), I'm going to reply to the patches themselves. I haven't yet
> done any testing, just visual review and sanity testing of the patches
> (make, make check, make distcheck, make rpms)
>
> But more importantly, I wonder what the benefit for an administrator would
> be over using libnfsidmap/nsswitch.so ? Since the names must be fully
> qualified the raw getpwnam() interface would yield the same usernames as
> the sssd module, right? Is it perhaps better multi-domain support ?
>


The main advantage of this new plugin  would be in a NFS server which is
not intended for users to log into.
Allowing the NSS layer (i.e. the OS, in the common man language) to be
aware of users is a potential security risk, and many times not desirable.
The direct interface between rpc.idmapd and sssd solves this issue. It
allows an administrator *not* to configure the OS to be aware of LDAP/AD
users but rather only the NFS component.

- Noam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20140620/ce45777f/attachment.html>


More information about the sssd-devel mailing list