2

I am using a MySQL backend to store some of my UNIX users into a database. In order for the system to be able to retrieve name information about these users, I added MySQL to NSS's sources:

passwd:         files mysql
group:          files mysql
shadow:         files mysql

However, when I request information about a user stored in /etc/passwd ("files" source), the MySQL backend is still queried (I can see the query I configured in /etc/libnss-mysql.cfg being executed).

Is there anyway I could have NSS stop after a match, so that MySQL isn't queried when the user/group is found using the typical UNIX authentication resources?

As you'll see in Edit 2, my problem appears when NSS tries to build the groups list, not when it looks up a specific name. This may be why the default SUCCESS => return chain isn't applied here.

Edit: I tried "forcing" NSS to return on first match using the following...

passwd:         files [SUCCESS=return] mysql
group:          files [SUCCESS=return] mysql
shadow:         files [SUCCESS=return] mysql

(despite the fact that return is supposed to be the default for the SUCCESS status), but MySQL is still queried. Removing mysql from the lines does restrict NSS to the files, so we can clearly say that even on SUCCESS, NSS continues.

Edit 2 (how I can see that MySQL is still queried) : my MySQL queries are such that when MySQL is queried, no matter what username you're querying about, the groups list returned will always contain GID 5000. So, for instance, if myuser (stored in the DB) belongs to mygroup (also stored in the DB), then MySQL will return both mygroup and GID 5000. Schematically, there is what you can observe:

mysql> SELECT * FROM grouplist WHERE username='myuser';
|---------------------------|
| GID           |  USERNAME |
|---------------------------|
| n             |  myuser   |
|---------------------------|

$ id myuser
uid=m(myuser) gid=n(mygroup) groups=n(mygroup),5000(forcedgroup)

                                                      ^^^^
                                            added for every SQL query

This little "addition" is made by the query itself:

gidsbymem   SELECT id FROM ( \
                SELECT id FROM grouplist WHERE username='%1$s' \
                UNION SELECT 5000 AS id \
            ) AS custom_groups

Now, when I request information about a user stored in /etc/passwd with id myotheruser, I can see GID 5000 in his groups, despite the fact that there is no such association in /etc/group. To me, what happens is that:

  • NSS reads /etc/passwd and finds myotheruser.
  • NSS queries my DB, does not find the user, but still returns GID 5000 as a group list.
  • myotheruser, who does not belong to any SQL group, has GID 5000 in its groups list, since MySQL added it.

Schematically:

$ id myotheruser
uid=n(myotheruser) gid=n(myothergroup) groups=n(myothergroup),5000(forcedgroup)

While I would expect:

$ id myotheruser
uid=n(myotheruser) gid=n(myothergroup) groups=n(myothergroup)

However, when I remove MySQL from NSS's sources, myotheruser no longer has GID 5000 in his list (which is why I can say that MySQL is the one adding it).

John WH Smith
  • 341
  • 4
  • 18
  • That's not expected behaviour. My experience (and the man page for nsswitch.conf) says that lookup terminates after successful match. Could nscd be confusing things? Perhaps (assuming this isn't a production server) turning ncsd off would clarify things. – Paul Haldane Nov 11 '14 at 17:30
  • @PaulHaldane Since I'm still testing my configurations, I haven't installed `nscd` yet (in order to prevent such problems from occuring while I'm setting the system up). – John WH Smith Nov 11 '14 at 17:33
  • Ah! When initialising a user's set of groups I would expect all backends to be used (because you're scanning a list rather than looking up a value). Perhaps the initgroups database in addition to group might help. I hadn't come across that until I read man page earlier. – Paul Haldane Nov 11 '14 at 21:55
  • I don't quite see how I could use the `initgroups` database here... No matter what I try, it's all or nothing: either everyone gets GID 5000, or no one does. – John WH Smith Nov 11 '14 at 22:04

0 Answers0