Parar NSSwitch no primeiro jogo

Question

Estou usando um backend do MySQL para armazenar alguns dos meus usuários do UNIX em um banco de dados. Para que o sistema possa recuperar informações de nome sobre esses usuários, adicionei o MySQL às fontes do NSS:

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

No entanto, quando solicito informações sobre um usuário armazenado em /etc/passwd (" files " source), o backend do MySQL ainda é consultado (eu posso ver a consulta que eu configurei em /etc/libnss-mysql.cfg sendo executada).

Existe alguma maneira que eu poderia fazer o NSS parar após uma correspondência, de modo que o MySQL não seja consultado quando o usuário / grupo for encontrado usando os recursos típicos de autenticação do UNIX?

Como você verá na Edição 2, meu problema aparece quando o NSS tenta criar a lista de grupos, não quando procura um nome específico. Talvez seja por isso que o padrão SUCCESS = > return chain não é aplicada aqui.

Edit: Eu tentei "forçar" o NSS a retornar no primeiro jogo usando o seguinte ...

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

(apesar do fato de que return deve ser o padrão para o SUCCESS status ), mas o MySQL ainda é consultado. Remover mysql das linhas restringe o NSS aos arquivos, por isso podemos dizer claramente que mesmo em SUCCESS , NSS continue s.

Edit 2 (como eu posso ver que o MySQL ainda é consultado) : minhas consultas ao MySQL são tais que quando o MySQL é consultado, não importa o nome de usuário que você esteja consultando, a lista de grupos retornada será sempre contém GID 5000. Então, por exemplo, se myuser (armazenado no banco de dados) pertencer a mygroup (também armazenado no banco de dados), o MySQL retornará mygroup e GID 5000. Esquematicamente, há o que você pode observar:

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

Essa pequena "adição" é feita pela própria consulta:

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

Agora, quando eu solicito informações sobre um usuário armazenado em /etc/passwd com id myotheruser , posso ver o GID 5000 em seus grupos, apesar do fato de não haver essa associação em /etc/group . Para mim, o que acontece é que:

• O NSS lê /etc/passwd e localiza myotheruser .
• O NSS consulta meu banco de dados, não encontra o usuário, mas ainda retorna o GID 5000 como uma lista de grupos.
• myotheruser , que não pertence a nenhum grupo SQL, possui o GID 5000 em sua lista de grupos, desde que o MySQL o adicionou.

Esquematicamente:

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

Enquanto eu esperaria:

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

No entanto, quando eu removo o MySQL dos fontes do NSS, myotheruser não tem mais o GID 5000 em sua lista (é por isso que posso dizer que o MySQL é o único que o adiciona).