Início / unix / Perguntas / 416852
Accepted
bfuvx
Asked: 2018-01-14 08:40:15 +0800 CST

rmdir falhou ao remover o diretório vazio

  • 772

Eu tenho um problema ao remover o diretório vazio, o strace mostra o erro:

rmdir("empty_dir") = -1 ENOTEMPTY (Directory not empty)

E ls -la empty_dirnão mostra nada. Então eu conectei ao fs (ext4) com debugfs e vi o arquivo escondido dentro deste diretório:

# ls -lia empty_dir/
total 8
44574010 drwxr-xr-x 2 2686 2681 4096 Jan 13 17:59 .
44573990 drwxr-xr-x 3 2686 2681 4096 Jan 13 18:36 ..

debugfs:  ls empty_dir
 44574010  (12) .    44573990  (316) ..  
 26808797  (3768) _-----------------------------------------------------------.jpg

Por que isso poderia acontecer? E alguma chance de resolver esse problema sem desmontar e verificar totalmente o fs?

Informação adicional:

O arquivo "oculto" é apenas um arquivo jpg normal e pode ser aberto pelo visualizador de imagens:

debugfs:  dump empty_dir/_-----------------------------------------------------------.jpg /root/hidden_file

# file /root/hidden_file 
/root/hidden_file: JPEG image data, JFIF standard 1.02

rm -rf empty_dirnão está funcionando com o mesmo erro:

unlinkat(AT_FDCWD, "empty_dir", AT_REMOVEDIR) = -1 ENOTEMPTY (Directory not empty)

find empty_dir/ -inum 26808797não mostra nada.

malware ext4

3 respostas

  1. Best Answer

    Eu rastreei lse obtive mais informações para cavar (remoção de syscalls não importantes):

    open("empty_dir", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 3 entries */, 32768)     = 80
write(1, ".\n", 2.)                     = 2
write(1, "..\n", 3..)                   = 3

    Hmm, vemos que o syscall getdentsfunciona corretamente e retornou todas as 3 entradas ('.','..' e '_---*'), mas lsescreveu apenas '.' e '..'. Isso significa que temos algum problema com o wrapper em torno getdentsdo qual é usado pelo coreutils. E os coreutils usam readdiro wrapper glibc para arquivos getdents. Também para provar que não há problemas com eu testei o pequeno prog da seção de exemplo da página de manualgetdents do getdents . Este programa mostrou todos os arquivos.

    Talvez tenhamos encontrado um bug no glibc? Então, atualizei o pacote glibc para a última versão da minha distro, mas não obtive nenhum bom resultado. Também não encontrei nenhuma informação correlata no bugzilla.

    Então vamos aprofundar:

    # gdb ls
(gdb) break readdir
(gdb) run
Breakpoint 1, 0x00007ffff7dfa820 in readdir () from /lib64/libncom.so.4.0.1
(gdb) info symbol readdir
readdir in section .text of /lib64/libncom.so.4.0.1

    Espere o que? libncom.so.4.0.1? Não é um libc? Sim, vemos apenas uma biblioteca compartilhada maliciosa com funções libc para ocultar atividades maliciosas:

    # LD_PRELOAD=/lib64/libc.so.6 find / > good_find
# find / > injected_find
# diff good_find injected_find
10310d10305
< /lib64/libncom.so.4.0.1
73306d73300
< /usr/bin/_-config
73508d73501
< /usr/bin/_-pud
73714d73706
< /usr/bin/_-minerd
86854d86845
< /etc/ld.so.preload

    Remoção de arquivos de rootkit, verificação de todos os arquivos de pacotes ( rpm -Vano meu caso), scripts de inicialização automática, configurações de pré-carregamento/pré-link, arquivos de sistema ( find /+ rpm -qfno meu caso), alteração de senhas afetadas, localização e eliminação de processos de rootkit:

    # for i in /proc/[1-9]*; do name=$(</proc/${i##*/}/comm); ps -p ${i##*/} > /dev/null || echo $name; done
_-minerd

    No final, atualização completa do sistema, reinicialização e problema resolvido. Motivo do hacking bem-sucedido: interface ipmi com firmware muito antigo que de repente estava disponível na rede pública.

    • 4

  2. Dentro debugfsde você pode deletar o arquivo. Você nem precisa do nome do arquivo (o que pode ser relevante se houver problemas com caracteres especiais como francois P adivinhou nos comentários):

    kill_file <26808797>
    • 1

  3. No meu caso, foi porque o sistema de arquivos foi montado como um compartilhamento cifs smb/samba com estas opções globais:

    [global]
   vfs objects = catia fruit streams_xattr
   fruit:aapl = yes

    Isso fornece compatibilidade com computadores Apple e seu desejo de criar fluxos de metadados secundários para todos os tipos de mídia (por exemplo, mp4).

    Mas a maneira como funciona é que ele cria dotfiles invisíveis (por exemplo , .apple.mp4para apple.mp4, que não podem ser removidos por um sistema remoto e que podem ficar fora de sincronia se o sistema local excluir, apple.mp4mas não o dotfile.

    A solução é voltar ao sistema local, onde os dotfiles são visíveis e podem ser rm'd.

    • 1

relate perguntas