Questão Por que “ls -a” oculta algum diretório existente do usuário root?


Hoje encontrei algo realmente interessante (pelo menos para mim) em um dos nossos servidores de teste:

Eu posso mudar para um diretório existente a partir do meu diretório de trabalho real usando um caminho relativo, mas esse mesmo diretório não está listado ao usar ls -a.

Aqui está a sessão de shell (como root):

$ pwd
/you/are/here
$ ls -a
. ..                       <-- Note: "somedir" is not shown to root
$ echo $CDPATH

$ cd somedir               <-- But still: "cd" works fine
$ pwd
/you/are/here/somedir
$ cd ..
$ pwd
/you/are/here
$ ls -a
. ..

Alguém poderia me dizer, como isso é possível? Eu conferi: ls é de /bin/lse pwd é /bin/pwd, ambos do seu pacote original (quero dizer: não hackeado).

/you é um disco EMC montado (ext3). E somedir existe como eu posso listar o conteúdo dele (existem vários subdiretórios, arquivos). Seu nome não começa com um ponto.

Mais algumas sessões de shell, com mais informações sobre os comandos e ls saída:

root@U-TEST@AT$/bin/ls -ali
total 4
16515074 drwxrwxr-x  2 U8000966 test 2048 Sep  1 07:39 .
16515073 drwxrwxr-x  3 U8000966 test 2048 Apr 27  2006 ..
root@U-TEST@AT$ls -ali somewhere | head -5
total 182
16515075 drwxrwxr-x  43 U8000966 test  2048 Sep  1 07:39 .
16515074 drwxrwxr-x   2 U8000966 test  2048 Sep  1 07:39 ..
16519169 drwxrwxrwx   4 U8000966 test  2048 Jul 25  2007 AAA
16515124 drwxrwxr-x   3 U8000966 test  2048 May 12  2006 BBB
root@U-TEST@AT$type ls
ls is aliased to `/bin/ls $LS_OPTIONS'
root@U-TEST@AT$type pwd
pwd is a shell builtin
root@U-TEST@AT$/bin/pwd
/you/are/here
root@U-TEST@AT$cd somewhere
root@U-TEST@AT$/bin/pwd
/you/are/here/somewhere
root@U-TEST@AT$type cd
cd is a shell builtin

Por favor, note o Total 4 depois do primeiro ls -ali. (Não sei se é relevante ...)

Mais alguns testes:

root@UR-TEST@AT$ls
.  ..
root@U-TEST@AT$touch somewhere/testfile
root@U-TEST@AT$ls
.  ..
root@U-TEST@AT$cp somewhere/testfile ./
root@U-TEST@AT$ls
.  ..  testfile
root@U-TEST@AT$du .
2       .
root@URBIS-TEST@AT$

E a EMC é: http://www.emc.com/products/family/disk-library-family.htm , mas eles são apenas um provedor de disco, neste caso, com discos rígidos, formatados como ext3.

ATUALIZAR

(Desculpe, mas ontem eu tive que sair)

Eu chequei echo *e sua saída é: . ... Aqui está o LS_OPTIONS: -a -N --color=tty -T 0.

Eu tinha verificado a coisa de automount mencionada por Gilles, mas como eu tinha mudado para somewhere e emitiu um mount|grep somewhere não houve saída.

Aqui está o lsattr e strace saída como sugerido: http://gist.github.com/566947 


2


origem


Alguém mais não consegue seguir esta questão? Você pode por favor rever como eu não posso entender o que você está pedindo. - Chris
Eu assumo isso somedir de fato existe? Quaisquer pistas ao digitar ls -a /you/are/here/somedir? - Arjan
@ Chris, ls -a não lista somedir (para root), mas ainda cd somedir funciona muito bem. - Arjan
ls is aliased to /bin/ls $LS_OPTIONS. Então, o que faz echo $LS_OPTIONS te dar então? (Embora eu duvide que seja relevante enquanto você também estava explicitamente usando /bin/ls com o mesmo resultado, e o intrigante "total 4" ...) - Arjan
Faça qualquer um echo *, ls -ld somedir, ls -lb ou ls -l|cat -v mostrar alguma coisa útil? - Dennis Williamson


Respostas:


Zsolt, por favor, tente estes três passos:

    1 cd /
    2 exec bash
    3 /usr/bin/find /you/are/here -ls

Provavelmente é hora de fsck... :-(

Mas antes disso, você poderia tentar (depois de fazer backup de qualquer coisa dentro somedir):
cd /you/are/here && mkdir somedir.
cd /you/are/here && ln somedir newdir (como root).

Verifique também mount | egrep -e 'somedir|you|are|here' para qualquer esquisitices.


3



Fiz isso, exceto o ciclo reboot / fsck (como não tenho permissão para fazer isso). o find também não encontrado somewhere. Eu posso criar o novo somedir diretório, e pode vincular a ele. Não consigo criar um somewhere dir, como se queixa, o arquivo já existe. Posso ligar para somewhere bem, e depois de um ls -l Posso ver uma listagem em que há um link para um diretório dentro do mesmo pai e não consigo ver o destino. - Zsolt Botykai
@Zsolt: Com licença, eu não entendo; fiz o mkdir somedir Passar ou falhar? Eu não faria mais nada neste sistema de arquivos (ou no here diretório), exceto backup. Está quebrado, ou o cache dele (no kernel) está corrompido. Se você tiver sorte, o fsck pode revincular o somedir diretório novamente. Se não, você pode perdê-lo. Parece-me que é hora de algum tempo de inatividade. Experimentar mv se você conseguiu vincular a ele. (mv somedir olddir; mv newdir somedir) se isso funciona, talvez você se atreva a unlink olddir? - MattBianco
Fsck achou: provavelmente foi algum erro no sistema de arquivos. O diretório somedir foi movido para lost+found. Agora estamos testando o disco para mais erros. - Zsolt Botykai


No momento em que escrevo isso, você não descartou os efeitos em algo $LS_OPTIONS. O GNU ls tem algumas opções de ignorar arquivos, e ls -I foo -a ainda ignora foo. Mas o resto da minha resposta assume que você obtém os mesmos resultados sem $LS_OPTIONS.

o total 4 linha não é, de fato, surpreendente. Este é o número total de blocos usados ​​por . e ... E se . está vazio e .. é pequeno e em um sistema de arquivos cujo tamanho de bloco é igual a blocos de 4 ls (o que é comum: o GNU ls é padronizado para blocos de 1kB e ext [234] frequentemente usa blocos de 4kB), então o total esperado é 0 + 1 * 4 = 4

Há algo incomum, mas não inédito, acontecendo com o sistema de arquivos que /you/are/here está ligado. Quando você pede o conteúdo de /you/are/here (com opendir() e readdir(3)), o sistema de arquivos responde apenas . e ..; ainda quando você assume que /you/are/here/somedir existe, você é dito que isso acontece. Isso é surpreendente, mas possível comportamento.

Uma explicação possível, mas altamente improvável, é um demônio (como em Demônio de Maxwellnão como em programa daemon) quem se move somedir no lugar apenas quando você acessá-lo e move-lo para fora do caminho quando você lista o diretório. Assim, a peculiaridade que você observa pode ser causada por um programa comum que, por acaso, faz as suposições certas, não indica nada de errado com o sistema operacional.

Na verdade, o sistema operacional provavelmente é comportando-se de maneira peculiar. Um culpado comum é um sistema de automontagem. A maneira como um sistema de montagem automática funciona normalmente é algo assim:

  • Um diretório, digamos /you/are/here, é configurado como um local para pontos de montagem. Um sistema de arquivos para fins especiais (possivelmente chamado autofs) está montado lá.

  • Quando você tenta acessar uma entrada em /you/are/heredigamos /you/are/here/somedir, o driver do sistema de arquivos tenta montar o somedir sistema de arquivo. Por exemplo, pode procurar por uma linha como somedir = /dev/foo ou somedir = server:/loca/tion em seu arquivo de configuração e monte o dispositivo indicado ou a localização NFS /you/are/here/somedir.

  • Quando você lista o diretório /you/are/here, você vê um subdiretório para cada sistema de arquivos atualmente montado.

  • Quando você para de usar /you/are/here/somedir, talvez após um atraso, o automounter desmonta somedir. assim somedir não aparece mais na listagem de /you/are/here.


5



Obrigado pelo link demoníaco do Maxwell, leitura interessante, e a explicação do automount é uma possibilidade. No entanto, eu suponho, se eu mudar para somewhereem seguida, emita um mount|grep somewhere e é montado naquele momento, deve ser listado, o que não é o caso. - Zsolt Botykai


O que "qual ls" ou "alias" mostra? Talvez o seu ls comando está sendo substituído por um alias ou algo semelhante? Executar o seguinte pode excluir isso:

/bin/ls -a /you/are/here

Algum fundo:

Um alias tem precedência sobre /bin/ls, ainda which ls ainda mostra /bin/ls. Você pode recriar o que estou me referindo a isto:

  1. Crie um script bash chamado ls, segurando:

    #!/bin/bash
    echo this is not ls
    
    • Crie um alias para o script bash:

      alias ls = '~ / ls'

    • Agora corra ls. Você deve receber "isso não é ls", ainda which ls mostra /bin/ls.

Também pode ser benéfico excluir o autofs / automount.

Depois de analisar as atualizações postadas ...

Talvez LS_OPTIONS contenha um --hide ou --ignore?

~/dirtest$ ls -a
.  ..  somewhere
~/dirtest$ ls -a --ignore='some*'
.  ..

O que...

echo $LS_OPTIONS

...exposição? Talvez até tente ...

unset LS_OPTIONS

... então re-execute o ls -a.

Pode ser que o LS_OPTIONS esteja sendo configurado em seu .bashrc ou outro arquivo de configuração. (talvez até no nível global, de / etc / bash * (ou qualquer arquivo de configuração apropriado para o shell em questão: .login, .profile, etc)


3



Eu acho Eu conferi: ls é de /bin/lse pwd é /bin/pwd, ambos da embalagem original refere-se a isso? - Arjan
Ainda assim, @Zsolt, executando explicitamente /bin/ls -a /you/are/here pode excluir isso e é facilmente testado? - Arjan
Não necessariamente. Um alias tem precedência sobre / bin / ls ... ainda 'qual ls' ainda mostra / bin / ls. Eu descartaria aliases e tal, ainda. Você pode recriar o que estou me referindo com isto: Crie um script bash chamado "ls". Adicione o típico #! / Bin / bas e uma segunda linha com algo como: echo, isso não é ls Crie um alias para o script bash ... algo como: alias ls = '~ / ls' Agora, execute ls. Você deve obter "isto não é ls", mas "which ls" mostra / bin / ls. Também pode ser benéfico excluir o autofs / automount ... - Matt
Sim, eu acho que o / bin / ls -a / you / are / aqui seria um ótimo teste. - Matt
Fiz assim, pergunta atualizada. - Zsolt Botykai


Você pode tentar outras ferramentas que podem andar na árvore de diretórios?

Por exemplo du -h obter o tamanho dos diretórios? Qual comportamento você observa se você iniciar isso a partir da raiz da unidade, ou de /you/are/here em comparação com /you/are/here/somedir?

Além disso - você pode criar um arquivo em /you/are/here/somedir? Em caso afirmativo, ele persiste quando você sai do diretório? A criação de um arquivo faz com que o diretório fique visível para ls comando?


2





O seguinte pode ou não ajudar, mas eu gostaria de ver a saída dos dois comandos a seguir:

$ lsattr -av somedir
$ strace ls -a somedir

0



Aqui está a saída: gist.github.com/566947 - Zsolt Botykai


Talvez algum processo esteja fazendo algo com o diretório. Você tentou lsof dirname, lsof /path/to/parent/* e lsof dirname/*?

Sobre o quê stat dirname?

Sobre o quê readlink -ev dirname?

Vejo que você fez type ls - o que type -a ls exposição?

Faz $PATH incluir algo incomum? Inclui . (ponto)?

Qual shell você está usando? Você já tentou fazer o seu original ls dirname em outro shell (especialmente depois de uma sessão completamente nova / login?

Se você estiver usando um shell com conclusão de tabulação, ele fará uma conclusão para o nome do diretório?

Você tem acesso a um gerenciador de arquivos ou GUI ou um modo de texto como mc(Midnight Commander) ou emacs dired? Eles podem navegar para dentro e fora desse diretório?

Eu suspeito seriamente que algo esteja corrompido ou hackeado.


0





LS ajuda fornece isso, que pode ser de alguma utilidade.

-a, --all                  do not ignore entries starting with .
-A, --almost-all           do not list implied . and ..
    --author               with -l, print the author of each file

0





Neste ponto, parece-me que a coisa mais provável é que o seu servidor foi invadido e foi carregado um rootkit que impede que o diretório apareça nas listagens. O kit raiz faria isso com um módulo do kernel que conecta ou redireciona as chamadas do sistema readdir e getdents. Se o módulo permanecer residente, provavelmente ele também estará se ocultando em / proc / modules ou por lsmod.


-1