Users visible in `getent passwd` but su <user> doesn't work.

[Michael Aldridge]

At the risk of posting to a dead list:

I built from source for my distro of choice and reconfigured my nsswitch.conf to be as follows:

$ cat /etc/nsswitch.conf                                                                                                                                                                                                
# /etc/nsswitch.conf
#
# See nsswitch.conf(5) for information.
#                                                                                                                                                                                                             passwd:         files cache                                                                                                                                                                                   group:          files cache                                                                                                                                                                                   shadow:         files                                                                                                                                                                                                                        
hosts:          files mdns mdns4_minimal mdns4 myhostname dns                                                                                                                                                 networks:       files                                                                                                                                                                                                                        
protocols:      files                                                                                                                                                                                         services:       files                                                                                                                                                                                         ethers:         files                                                                                                                                                                                         rpc:            files

User "foo" is provided by the network and shows up in

$ getent passwd foo
foo:x:10000:5000:::
$ id foo
uid=10000(foo) gid=5000(mygroup) groups=5000(mygroup)

As you can see, id(1) also resolves them and shows the group resolved as well (the group is also provided by the network.

However, despite these users appearing to be visible to NSS, commands which would need them don't seem to work:

$ sudo su foo
su: user foo does not exist

Any thoughts?

[Jamie Wilkinson]

Your nsswitch.conf is hard to read in this message.  I assume that's a copy-and-paste problem and not that the lines are accidentally concatenated.

How did you generate the config?  Can you show the commandline, and perhaps some (redacted) /etc/nsscache.conf ?  Does nsscache verify report everything is OK?

Can you double check that the contents of /etc/passwd.cache contain foo?

One old trick we used for verifying the call path was to use strace, e.g. sudo strace su foo.  Look for what happens with the getpwent calls.  My first guess would be that the su call has a different setup to id; perhaps (wild guess) with /etc/security/limits.conf or something like that.  Sorry, it's been a while since I understood this.

--
You received this message because you are subscribed to the Google Groups "nsscache-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nsscache-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Aldridge]

Indeed, something seems off in the way my message was formatted, I've
tried again in this message with the html formatting dumped.

Here is the nsswitch.conf (the relavant bits):

$ cat /etc/nsswitch.conf

passwd: files cache
group: files cache
shadow: files

By config I'm not sure what you mean, I edited nsswitch.conf with a
text-editor. I generated
/etc/{passwd,group}.cache{,.ixname,ix{gid,uid}} with some code written
in Golang available here:
https://git.michaelwashere.net/NetAuth/nsscached/src/branch/master/cmd/nsscached/main.go#L103.
I have not used nsscache verify as I suspect that since I didn't use it
to generate the file in the first place it won't do the right thing.

I suspect my code has an error in it though as I have to rm the .ix*
files to get things to work correctly. However if I remove the index
files, then getent works. I assume for the moment that I can operate
without the indexes and things work, just slower.

The contents of /etc/passwd.cache and /etc/group.cache are:
$ cat /etc/passwd.cache
foo:x:10000:5000:::
$ cat /etc/group.cache
mygroup:x:5000:foo

This is a test VM with just the directory service and one user in it, so
that is what I expect these files to contain.

Here's the output of strace when trying to su:
https://hastebin.com/omabidocib.erl

It reads the passwd.cache file, but I don't see anything out of the
ordinary that would be a crash here. My /etc/security/limits.conf is
blank, and I've also tested this with login(1) which should definitely
go through NSS, so I'm at a bit of a loss here.

[Michael Aldridge]

Ok, the plot thickens, I can sudo -u foo, but I cannot sudo su foo. I'm
inclined to think at this point that it might be a PAM issue rather than
an issue in NSS.

[Jamie Wilkinson]

Thanks for following up.   I didn't realise you weren't using nsscache to generate the cache and indexes.  If you want to look at github.com/google/nsscache you can find the python code that generates the index format.  With short cache files, and no index, the nss library will fall back to a linear search through the file, this is why removing the files worked for you.

Your password cache entry has no shell or homeir, so maybe your theory is correct that it's PAM blocking you.  The strace doesn't explain why the program says "does not exist" but given that the nss lookup has returned the correct object, I'd try adding a shell or homedir and seeing if that changes things.

Good luck!

[Michael Aldridge]

Thanks for the link, my index issue turned out to be me not proofreading
my own code; there's a big difference between 0 index and 1 indexed
columns...

My hunch that its PAM at this point comes from sudo is opening the shell
with sudo:session in the auth log whereas I don't get that far with my
local pam_* functions. Since I'm not implementing the session functions
in my PAM module it would make sense that pam_unix.so will return
PAM_USER_UNKNOWN, who's message in string form I believe should be of
the form "user %s does not exist".

I'm still investigating this, but I think at this point I may have
gotten it nailed down to a buggy PAM implementation.

--Michael

[Michael Aldridge]

Having solved it, the problem was that I wasn't generating a
shadow.cache or shadow.cache.ixname. I had forgotten that the passwd
maps aren't considered valid without the corresponding line in the
shadow file, even if the shadow file doesn't contain a password.

--Michael

[Jamie Wilkinson]

Ow!  Glad you figured it out!