Nenhuma saída do comando locate

Question

Eu costumo encontrar as respostas para todos os meus problemas relacionados ao Unix já postados como perguntas e respostas. No entanto, esse problema específico me deixou perplexo na última hora, então pensei em fazer minha primeira pergunta neste site.

Problema

Eu tenho um servidor servidor de desenvolvimento / temporariedade executando o CentOS 5.11. Executar locate como um usuário comum resulta em nenhuma saída (nem mesmo uma mensagem de erro):

locate readdir

No entanto, a execução do comando como superusuário imprime uma lista de resultados válidos:

$ sudo locate readdir
/home/anthony/repos/php-src/TSRM/readdir.h
/home/anthony/repos/php-src/ext/standard/tests/dir/readdir_basic.phpt
... etc.

strace geralmente me ajuda a depurar esses problemas e a executar strace locate readdir shows:

stat64("/var/lib/mlocate/mlocate.db", 0xbff65398) = -1 EACCES (Permission denied)
access("/", R_OK|X_OK)                  = -1 EACCES (Permission denied)
exit_group(1)                           = ?

Verifique as permissões

Eu verifiquei a propriedade e as permissões do binário locate e seu banco de dados padrão. Como esperado, o comando é setgid com slocate como o proprietário do grupo enquanto o banco de dados possui a propriedade e as permissões apropriadas.

$ ls -l /usr/bin/locate
-rwx--s--x 1 root slocate 22280 Sep  3  2009 /usr/bin/locate

$ sudo ls -l /var/lib/mlocate/mlocate.db
-rw-r----- 1 root slocate 78395703 May  8 04:02 /var/lib/mlocate/mlocate.db

$ sudo ls -ld /var/lib/mlocate/
drwxr-x--- 2 root slocate 4096 Sep  3  2009 /var/lib/mlocate/

Também não há atributos de arquivo incomuns:

$ sudo lsattr /usr/bin/locate /var/lib/mlocate/mlocate.db
------------- /usr/bin/locate
------------- /var/lib/mlocate/mlocate.db

Compare com o sistema de trabalho

Enquanto isso, tudo funciona conforme o esperado no servidor de produção. A execução de locate readdir como usuário regular (não raiz) retorna uma lista de resultados como deveria:

$ locate readdir
/usr/include/php/TSRM/readdir.h
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/POSIX/readdir.al
/usr/share/man/man2/readdir.2.gz

Para fins de comparação, eu também executei este comando através de strace , mas recebi a mesma permissão negada de erro do servidor de teste. Eu queria saber como isso poderia ser até que eu li a página de manual para sudo . Listado na seção Bugs :

Programs that use the setuid bit do not have effective user ID privileges while being traced.

Então, infelizmente, não posso usar strace para depuração.

Eu comparei os resultados de todos os comandos acima entre os servidores de teste e produção e não há diferença entre eles. Ambos os sistemas têm o mlocate-0.15-1.el5.2 RPM sem modificações em seus arquivos, como mostrado por rpm -V mlocate .

Outras considerações

Pensei que poderia estar relacionado ao fato de que, no servidor de teste problemático, meu login é autenticado usando o Winbind, mas criei um usuário local regular na mesma caixa e ainda tenho o mesmo problema. Há obviamente outra coisa que eu sinto falta, mas eu simplesmente não sei o que é isso.

Eu suspeito que isso esteja relacionado à permissão do arquivo setgid, talvez ao PAM ou possivelmente ao SELinux. Não sei muito sobre o PAM ou o SELinux: só vi o PAM ao configurar a autenticação do Winbind enquanto o SELinux foi instalado com o SO, mas nunca o usei.

Nota: o servidor de produção foi submetido a muito menos modificações do que o servidor de desenvolvimento que teve alguma experimentação.

Editar: problema resolvido

Graças ao olho atento de Celada e atenção aos detalhes, verifiquei as permissões do diretório raiz.

$ sudo ls -ld /
drwx--xr-x 25 root domain users 4096 Apr 22 17:57 /

Quando autentico usando minhas credenciais do Active Directory, domain users é o grupo principal alocado para mim pelo Winbind. Um tempo atrás, eu estava negando privilégios de leitura em um conjunto de diretórios para outros usuários, alterando a propriedade do grupo e removendo a permissão de leitura do grupo. Eu devo ter acidentalmente feito o mesmo com o diretório raiz. Doh! Curiosamente, isso foi há algumas semanas e eu não notei nenhum problema - embora isso tenha coincidido com o momento em que eu conscientemente decidi iniciar o login como um usuário comum e usar o sudo em vez de fazer login como root.

De qualquer forma, alterei as permissões de volta para o que elas deveriam ser:

$ sudo chgrp root /
$ sudo chmod -v g+r /
mode of '/' changed to 0755 (rwxr-xr-x)

$ ls -ld /
drwxr-xr-x 25 root root 4096 Apr 22 17:57 /

Agora, locate funciona como deveria.

    

Answer 1

O problema eram as permissões para / (o diretório raiz) e a pista para descobrir que era essa linha do seu strace output:

access("/", R_OK|X_OK)                  = -1 EACCES (Permission denied)

Você estava sem configurações de permissão de leitura de grupo para / . Mas como você ainda tinha a permissão x (execute), que permite percorrer um diretório, ainda é possível acessar todos os arquivos no sistema de arquivos, e é por isso que quase tudo continuou funcionando enquanto essas permissões estavam em vigor. A única coisa que você não pode fazer é listar o conteúdo de / . A maioria dos comandos não precisa listar / , eles usam nomes de caminho relativos ao diretório atual ou nomes de caminhos absolutos que acessam diretórios conhecidos específicos da raiz (como /etc e /var ).

Por motivos de segurança, locate , embora tenha acesso a um inventário completo de nomes de arquivos gerados por um usuário privilegiado, insiste em relatar somente os resultados que o usuário chamador conseguirá localizar, examinando todo o sistema de arquivos a partir da raiz . Como você não pode listar / , o que torna a varredura de algo direto da raiz como não-inicial, locate não reportaria nada.