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 continue
s.
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 findsmyotheruser
. - 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).