nss_getpwnam: name '<email address hidden>@XX.XX.EDU' domain 'XX.XX.EDU': resulting localname '(null)'

I was able to find a solution to this issue that will require a patch/update to the libnfsidmap to version 0.26.

Please see reference to another user that experience the issue.

https://<email address hidden>/thread/SIA6J7IZRWX2FVGHKMS5F3HB7DE3MCFC/

I confirmed after custom compiling and using the newer lib's .so file that the naming convention was normal. One directory timed out when I did a chown but after fixing the file permissions to a user inside AD it seems to be working alright.

Can you please patch libnfsidmap to use version 0.26 to fix this bug? Thanks!

I'm having trouble finding the correct upstream for libndsifmap. The URL the packages point at (http://www.citi.umich.edu/projects/nfsv4/linux/) only lists 0.25

Google shows me https://github.com/Distrotech/libnfsidmap as a git repo, but last commit there is from 2013, and the mirror it claims to be from gives a 403.

I then downloaded the 0.26 tarball from http://www.linuxfromscratch.org/blfs/view/systemd/general/libnfsidmap.html, did a diff to what we have in the packages, and maybe this is the fix that was mendioned in that mailing list thread?

diff -uNr '--exclude=.git' '--exclude=debian' libnfsidmap-0.25/nss.c libnfsidmap-0.26/nss.c
--- libnfsidmap-0.25/nss.c 2011-12-05 18:28:10.000000000 -0200
+++ libnfsidmap-0.26/nss.c 2014-08-13 13:42:14.000000000 -0300
@@ -135,7 +135,7 @@
    char *l = NULL;
    int len;

- c = strchr(name, '@');
+ c = strrchr(name, '@');
    if (c == NULL && domain != NULL)
        goto out;
    if (c == NULL && domain == NULL) {

But there are many other changes. It would help to get the git repo for this project, wherever it is maintained now.

Looks like this commit your looking for is rather old since it doesn't show
up for me in the following file on that repo:
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=history;f=support/nfsidmap/nss.c

Perhaps Steve Dickson can tell us where he forked the repository from
previously and if it still exists?

*Michael Allen Barkdoll*
Computer Systems Architecture Specialist
Email: <email address hidden> | Phone: 618-453-6051
****************************************************************************************************
Department of Computer Science, Southern Illinois University of Carbondale
Engineering A0311C, Mail Code 4511, 1230 Lincoln Drive, Carbondale, IL 62901
Main Office: 618-536-2327 | Fax: 618-453-6044 | Lab Assistants: 618-453-6052
****************************************************************************************************

On Thu, Mar 14, 2019 at 9:39 AM Michael Barkdoll <email address hidden>
wrote:

> Hi Andreas,
>
> I think the repo might be here:
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=summary
>
> Source:
> http://www.citi.umich.edu/projects/nfsv4/linux/
> Links to: "Any recent distribution should include kernels and userspace
> utilities with NFSv4 and rpcsec_gss support, and development versions can
> generally be found at linux-nfs.org."
> http://linux-nfs.org/wiki/index.php/Main_Page
> Links to:
> nfs-utils code repository:
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=summary
>
> The snapshots have the nss.c code that you've found that appears to be the
> bug. I'm guessing this is the original source of the code. I can try to
> help as well just let me know what I'd need to do, thanks.
> Michael Barkdoll
>
>

Thank you for confirming the bug, it looks like libnfsidmap's code base was
imported into nfs-utils by Redhat on 10/26/2017 by Justin Mitchell, it
already had the line modification inside nss.c at that point.

I found where the commit was made, it was on the master branch of
https://github.com/Distrotech/libnfsidmap

You can see it here:
https://github.com/Distrotech/libnfsidmap/commits/master/nss.c
https://github.com/Distrotech/libnfsidmap/commit/309a89975a50bf53c408233a1bb5b10fd579ca30#diff-61814500c84b4fbb0fbdc21f11f4ea2c

<https://github.com/Distrotech/libnfsidmap/commit/309a89975a50bf53c408233a1bb5b10fd579ca30#diff-61814500c84b4fbb0fbdc21f11f4ea2c>

On Fri, Mar 15, 2019 at 7:20 AM Bug Watch Updater <
<email address hidden>> wrote:

> ** Changed in: libnfsidmap (Debian)
> Status: Unknown => New
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1819197
>
> Title:
> nss_getpwnam: name '<email address hidden>@XX.XX.EDU' domain 'XX.XX.EDU':
> resulting localname '(null)'
>
> Status in libnfsidmap package in Ubuntu:
> New
> Status in nfs-utils package in Ubuntu:
> New
> Status in libnfsidmap package in Debian:
> New
>
> Bug description:
> uid and gid appear to not map properly from nfsidmap in a nfsv4 with
> sec=krb5. UID and GID are mapping properly on CentOS server and
> CentOS client. Ubuntu nfs client file permissions are honored, but
> display in `ls -lan` command are incorrect.
>
> $ cat /var/log/syslog |grep nfsidmap
> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: key: 0x24a1c64d type: uid
> value: <email address hidden>@XX.XX.EDU timeout 600
> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: nfs4_name_to_uid: calling
> nsswitch->name_to_uid
> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: nss_getpwnam: name
> '<email address hidden>@XX.XX.EDU' domain 'XX.XX.EDU': resulting localname
> '(null)'
> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: nss_getpwnam: name
> '<email address hidden>@XX.XX.EDU' does not map into domain 'XX.XX.EDU'
> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: nfs4_name_to_uid:
> nsswitch->name_to_uid returned -22
> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: nfs4_name_to_uid: final
> return value is -22
> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: nfs4_name_to_uid: calling
> nsswitch->name_to_uid
> $
> $ mount -v -t nfs4 -o sec=krb5 SP19SRV.XX.XX.EDU:/export /mnt
> $ su userX
> $ ls -la /mnt
> total 4
> drwxr-xr-x 5 nobody 4294967294 50 Feb 28 18:04 .
> drwxr-xr-x 24 root root 4096 Mar 7 22:34 ..
> drwxr-xr-x 2 nobody 4294967294 125 Mar 8 16:27 userX
> $
>
> Problem:
> nfsmapid isn't showing proper file permissions on the ubuntu nfsv4
> client with sec=krb
>
> Client:
> mount -v -t nfs4 -o sec=krb5 SP19SRV.XX.XX.EDU:/export /mnt
>
> $ ls -la
> total 4
> drwxr-xr-x 5 nobody 4294967294 50 Feb 28 18:04 .
> drwxr-xr-x 24 root root 4096 Mar 7 20:58 ..
> drwxr-xr-x 2 nobody 4294967294 112 Mar 7 14:30 username
> <email address hidden>@ubuntuclient:/mnt
>
> $ cat /etc/idmapd.conf
> [General]
>
> Verbosity = 9
> Pipefs-Directory = /run/rpc_pipefs
> # set yo...

This appears to be directly related to:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581199

They submitted a patch there that does an additional modification to nss.c
for

The patch fixes the problem if not using kerberos.
I checked the latest version (0.23, in testing and unstable packages.
doesn't apply for oldstable and stable ones) from citi's website and it
seems there's an additional fix to make for function
"nss_gss_princ_to_ids" in nss.c file on line 279 :

/////////////////////////////////////////////////

    /* get princ's realm */
    princ_realm = strstr(princ, "@");
    if (princ_realm == NULL)
        return -EINVAL;
    princ_realm++;

////////////////////////////////////////////////

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=581199;filename=libnfsidmap_0.25-5ubuntu1.debdiff;msg=15

Michael Barkdoll

On Fri, Mar 15, 2019 at 8:42 AM Michael Barkdoll <email address hidden>
wrote:

> Thank you for confirming the bug, it looks like libnfsidmap's code base
> was imported into nfs-utils by Redhat on 10/26/2017 by Justin Mitchell, it
> already had the line modification inside nss.c at that point.
>
> I found where the commit was made, it was on the master branch of
> https://github.com/Distrotech/libnfsidmap
>
> You can see it here:
> https://github.com/Distrotech/libnfsidmap/commits/master/nss.c
>
> https://github.com/Distrotech/libnfsidmap/commit/309a89975a50bf53c408233a1bb5b10fd579ca30#diff-61814500c84b4fbb0fbdc21f11f4ea2c
>
>
>
> <https://github.com/Distrotech/libnfsidmap/commit/309a89975a50bf53c408233a1bb5b10fd579ca30#diff-61814500c84b4fbb0fbdc21f11f4ea2c>
>
> On Fri, Mar 15, 2019 at 7:20 AM Bug Watch Updater <
> <email address hidden>> wrote:
>
>> ** Changed in: libnfsidmap (Debian)
>> Status: Unknown => New
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1819197
>>
>> Title:
>> nss_getpwnam: name '<email address hidden>@XX.XX.EDU' domain 'XX.XX.EDU':
>> resulting localname '(null)'
>>
>> Status in libnfsidmap package in Ubuntu:
>> New
>> Status in nfs-utils package in Ubuntu:
>> New
>> Status in libnfsidmap package in Debian:
>> New
>>
>> Bug description:
>> uid and gid appear to not map properly from nfsidmap in a nfsv4 with
>> sec=krb5. UID and GID are mapping properly on CentOS server and
>> CentOS client. Ubuntu nfs client file permissions are honored, but
>> display in `ls -lan` command are incorrect.
>>
>> $ cat /var/log/syslog |grep nfsidmap
>> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: key: 0x24a1c64d type: uid
>> value: <email address hidden>@XX.XX.EDU timeout 600
>> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: nfs4_name_to_uid: calling
>> nsswitch->name_to_uid
>> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: nss_getpwnam: name
>> '<email address hidden>@XX.XX.EDU' domain 'XX.XX.EDU': resulting localname
>> '(null)'
>> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: nss_getpwnam: name
>> '<email address hidden>@XX.XX.EDU' does not map into domain 'XX.XX.EDU'
>> Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: nfs4_name_to_uid:
>> nsswitch->name_to_uid returned -22
>> Mar 8 16:38:34 ubuntuclient nfs...

I'm sorry, I must have written my previous comment somewhere else, as I don't see it here.

I built the a package with the first patch in a PPA at https://launchpad.net/~ahasenack/+archive/ubuntu/libnfsidmap-krb5-1819197/

It doesn't yet have the second hunk you just found.

Oh :/

Found at least two other occurrences where people submitted this patch and nothing was done:

- bug #1728310
- bug #584942

Thanks, Andreas,

Your package fixed the issue that I was experiencing with just the one line modification. I specifically tested:

https://launchpad.net/~ahasenack/+archive/ubuntu/libnfsidmap-krb5-1819197/+files/libnfsidmap2_0.25-5.1ubuntu0.1~ppa1_amd64.deb

# ls -la /mnt
total 4
drwxr-xr-x 4 nobody 4294967294 38 Mar 12 20:31 .
drwxr-xr-x 24 root root 4096 Mar 15 19:24 ..
drwxr-xr-x 3 <email address hidden> domain <email address hidden> 31 Mar 12 20:37 userY
drwxr-xr-x 2 <email address hidden> domain <email address hidden> 31 Mar 12 20:35 test
root@ubuntuclient:~#

Thanks for testing!

I'll take a look at the full patch as well, after I'm done with some other troubleshooting I'm doing elsewhere.

Andreas,

I downloaded the package from source and tried applying both modifications that people talk about making. The second modification (the one you hadn't made on line 279) actually breaks my `ls -la`.

# ls -la /mnt
total 4
drwxr-xr-x 4 4294967294 4294967294 38 Mar 12 20:31 .
drwxr-xr-x 24 root root 4096 Mar 15 20:10 ..
drwxr-xr-x 3 4294967294 4294967294 31 Mar 12 20:37 userY
drwxr-xr-x 2 4294967294 4294967294 31 Mar 12 20:35 test
root@ubuntuclient:~#

I notice that line isn't inside the latest upstream code as well.

The patch attached here works for me and is what was used I believe in your .deb files linked above.

Sorry, I had a typo on the second patch that applied to strrchr line 279. I put strrstr instead :(

Anyway, that patch actually works and doesn't break anything. I'm not sure why the upstream doesn't have the line on 279. I'm attaching what I used here.

The attachment "03-nss.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Version 0.27, which is a release from Steve apparently (I emailed him asking) doesn't have the second bit in the patch either, just the first. Just looking at the code I can't tell if it's needed or not, depends on what the "princ" variable is in the nss_gss_princ_to_ids() function. If it's really just a principal, i.e., <email address hidden>, then the strstr call is ok. It's not clear to me when that is used.

I may try to bring up such a setup myself to check. I don't think I should need an Active Directory server for that (hopefully).

The second hunk has a small mistake:
+ princ_realm = strrchr(princ, "@");

That should be using single quotes:

+ princ_realm = strrchr(princ, '@');

I'm trying to wrap my head around the terminology here, maybe you can help me.

sssd is making your domain users have a username of user@DOMAIN. That "DOMAIN" bit, however, is also the kerberos 5 realm, correct? And you have a different NFSv4 "domain"? So the name that the NFSv4 server sends over the wire (instead of a uid) is "user@DOMAIN@nfsv4domain"? Or, in other words, "user@REALM@nfsv4domain"?

I'm trying to determine if the second hunk of the patch is necessary, under what conditions. So far I only got it to run when I ran the libtest.c test program, from the libnfsidmap source code:

$ ./libtest andreas@lowtech andreas@LOWTECH
nfs4_gss_princ_to_ids: princ andreas@LOWTECH has uid 1000 gid 1000
nfs4_name_to_uid: name andreas@lowtech has uid 1000
nfs4_name_to_gid: name andreas@lowtech has gid 1000
 nfs4_gss_princ_to_grouplist: princ andreas@LOWTECH has gids 1000 4 24 27 30 46 108 109 125 127 129 999 132
nfs4_uid_to_name: uid 1000 has name andreas@lowtech
nfs4_gid_to_name: gid 1000 has name andreas@lowtech

But the princ parameter given to it us a normal principal name, with just one "@", so it doesn't matter if strstr() or strrchr() is used.

This bug was fixed in the package libnfsidmap - 0.25-5.1ubuntu1

---------------
libnfsidmap (0.25-5.1ubuntu1) disco; urgency=medium

  * d/p/03-uid-map-krb5.patch: fix uid mapping when sec=krb5 is used
    (LP: #1819197)

 -- Andreas Hasenack <email address hidden> Fri, 22 Mar 2019 09:22:23 -0300

I'm seeing this on 18.04/bionic. What needs to happen to get it released there? Thanks.

I'm testing a local build of the bionic package change linked in this bug and so far so good.