Como posso substituir lsof dentro de um Docker (nativo, não baseado em LXC)

16

Estou um pouco confuso que dentro de um contêiner do Docker lsof -i não produza nenhuma saída.

Exemplo (todos os comandos / saída de dentro do contêiner):

[1] root@ec016481cf5f:/# lsof -i
[1] root@ec016481cf5f:/# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -

Por favor, note também que nenhum PID ou nome do programa é mostrado por netstat . fuser também fornece resultados um pouco confusos e é incapaz de identificar os PIDs também.

Alguém pode lançar alguma luz sobre isso?

  • Como posso substituir lsof -i (para ver o nome do processo também!)
  • Por que a saída de netstat está prejudicada também?

NB: O contêiner é executado com "ExecDriver": "native-0.1" , que é a camada de execução do Docker, não o LXC.

[1] root@ec016481cf5f:/# fuser -a4n tcp 22
Cannot stat file /proc/1/fd/0: Permission denied
Cannot stat file /proc/1/fd/1: Permission denied
Cannot stat file /proc/1/fd/2: Permission denied
Cannot stat file /proc/1/fd/3: Permission denied
Cannot stat file /proc/1/fd/255: Permission denied
Cannot stat file /proc/6377/fd/0: Permission denied
Cannot stat file /proc/6377/fd/1: Permission denied
Cannot stat file /proc/6377/fd/2: Permission denied
Cannot stat file /proc/6377/fd/3: Permission denied
Cannot stat file /proc/6377/fd/4: Permission denied
22/tcp:

(Eu não estou obcecado pelo Permission denied , porque isso figura. O que me confunde é a lista vazia de PIDs após 22/tcp .)

# lsof|awk '$1 ~ /^sshd/ && $3 ~ /root/ {print}'
sshd    6377      root  cwd   unknown                        /proc/6377/cwd (readlink: Permission denied)
sshd    6377      root  rtd   unknown                        /proc/6377/root (readlink: Permission denied)
sshd    6377      root  txt   unknown                        /proc/6377/exe (readlink: Permission denied)
sshd    6377      root    0   unknown                        /proc/6377/fd/0 (readlink: Permission denied)
sshd    6377      root    1   unknown                        /proc/6377/fd/1 (readlink: Permission denied)
sshd    6377      root    2   unknown                        /proc/6377/fd/2 (readlink: Permission denied)
sshd    6377      root    3   unknown                        /proc/6377/fd/3 (readlink: Permission denied)
sshd    6377      root    4   unknown                        /proc/6377/fd/4 (readlink: Permission denied)
sshd    6442      root  cwd   unknown                        /proc/6442/cwd (readlink: Permission denied)
sshd    6442      root  rtd   unknown                        /proc/6442/root (readlink: Permission denied)
sshd    6442      root  txt   unknown                        /proc/6442/exe (readlink: Permission denied)
sshd    6442      root    0   unknown                        /proc/6442/fd/0 (readlink: Permission denied)
sshd    6442      root    1   unknown                        /proc/6442/fd/1 (readlink: Permission denied)
sshd    6442      root    2   unknown                        /proc/6442/fd/2 (readlink: Permission denied)
sshd    6442      root    3   unknown                        /proc/6442/fd/3 (readlink: Permission denied)
sshd    6442      root    4   unknown                        /proc/6442/fd/4 (readlink: Permission denied)
sshd    6442      root    5   unknown                        /proc/6442/fd/5 (readlink: Permission denied)

Existe mais alguma saída para o usuário conectado, que também é identificado corretamente, mas é isso. É aparentemente impossível discernir de qual tipo ( lsof -i limita aos sockets de internet) um certo "objeto" é.

    
por 0xC0000022L 12.06.2014 / 02:21

4 respostas

7

(OBSERVAÇÃO: não está claro na pergunta como o usuário está inserindo o contêiner docker. Estou assumindo docker exec -it CONTAINER bash foi usado.)

Eu tive esse problema ao usar uma imagem do docker com base em centos:7 com a versão do docker 1.9.0 e, para superar isso, acabei de executar:

docker exec --privileged -it CONTAINER bash

Observe a inclusão de --privileged .

Meu entendimento ingênuo do motivo é necessário: parece que o docker faz um esforço para ter o contêiner mais "seguro", como documentados aqui .

    
por 19.02.2016 / 03:16
4

Hah, o enredo engrossa. Se alguém tiver uma resposta melhor, escreva-a e aceitarei, se for aceitável. Mas aqui a razão aparente. Quão negligente de ignorar os arquivos de log no host :

Jun 12 01:29:46 hostmachine kernel: [140235.718807] audit_printk_skb: 183 callbacks suppressed
Jun 12 01:29:46 hostmachine kernel: [140235.718810] type=1400 audit(1402536586.521:477): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=3782 comm="lsof" requested_mask="trace" denied_mask="trace" peer="docker-default"
Jun 12 01:29:46 hostmachine kernel: [140235.718860] type=1400 audit(1402536586.521:478): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=3782 comm="lsof" requested_mask="read" denied_mask="read" peer="docker-default"
Jun 12 01:29:46 hostmachine kernel: [140235.718886] type=1400 audit(1402536586.521:479): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=3782 comm="lsof" requested_mask="read" denied_mask="read" peer="docker-default"
Jun 12 01:29:46 hostmachine kernel: [140235.718899] type=1400 audit(1402536586.521:480): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=3782 comm="lsof" requested_mask="read" denied_mask="read" peer="docker-default"
Jun 12 01:29:46 hostmachine kernel: [140235.718921] type=1400 audit(1402536586.521:481): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=3782 comm="lsof" requested_mask="read" denied_mask="read" peer="docker-default"
Jun 12 01:29:46 hostmachine kernel: [140235.718954] type=1400 audit(1402536586.521:482): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=3782 comm="lsof" requested_mask="read" denied_mask="read" peer="docker-default"
Jun 12 01:29:46 hostmachine kernel: [140235.719001] type=1400 audit(1402536586.521:483): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=3782 comm="lsof" requested_mask="read" denied_mask="read" peer="docker-default"
Jun 12 01:29:46 hostmachine kernel: [140235.719043] type=1400 audit(1402536586.521:484): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=3782 comm="lsof" requested_mask="read" denied_mask="read" peer="docker-default"
Jun 12 01:29:46 hostmachine kernel: [140235.719086] type=1400 audit(1402536586.521:485): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=3782 comm="lsof" requested_mask="read" denied_mask="read" peer="docker-default"
Jun 12 01:29:46 hostmachine kernel: [140235.719126] type=1400 audit(1402536586.521:486): apparmor="DENIED" operation="ptrace" profile="docker-default" pid=3782 comm="lsof" requested_mask="read" denied_mask="read" peer="docker-default"

Assim apparmor parece ser o culpado, embora eu tenha que descobrir como convencê-lo a permitir isso sem comprometer a segurança do host / contêiner ou para ver se é possível sem comprometer a segurança.

    
por 12.06.2014 / 03:32
3

Outra possibilidade, desta vez com uma configuração de segurança mais refinada: conceda o privilégio SYS_PTRACE ao contêiner docker:

docker run --cap-add=SYS_PTRACE ...
    
por 08.08.2016 / 18:42
2

Eu também encontrei esse problema. O problema ocorreu depois que eu desabilitei apparmor on docker :

$ sudo aa-complain <docker apparmor profile name, "docker-default" on ubuntu>

URL de referência: link

    
por 08.07.2014 / 08:04