Docker内でlsofを置換するにはどうすればよいですか(LXCベースではなくネイティブ)


16

Dockerコンテナー内でlsof -iは出力が得られないことに多少困惑しています。

例(コンテナ内からのすべてのコマンド/出力):

[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      -

また、PIDまたはプログラム名がによって表示されないことに注意してくださいnetstatfuserまた、やや紛らわしい出力が得られ、PIDを特定することもできません。

誰もこれに何か光を当てることができますか?

  • どうすれば置換できますかlsof -iプロセス名も表示されます!)
  • なぜ出力もnetstat不自由になるのですか?

注:コンテナーはで"ExecDriver": "native-0.1"実行されます。これはLXCではなく、Docker独自の実行レイヤーです。


[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:

(私はPermission denied、その数字に夢中です。私を混乱させるのは、の後のPIDの空のリストです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)

接続されたユーザーにはさらにいくつかの出力があり、これも正しく識別されますが、それだけです。lsof -i特定の「オブジェクト」がどのタイプ(インターネットソケットの制限)であるかを見分けることは明らかに不可能です。


lsofレポートとは何ですか?同じ?
slm

@slm:素晴らしい問い合わせ!空にしない。代わりに、(sshd関連する)行のホスト全体を表示します。その一部は、TCPソケットである可能性がありますTYPE unknown。独特。出力を質問に追加します。
0xC0000022L

実行strace -s 2000 -o lsof.log lsof -iすると、ブロックされているものに関する追加の洞察が得られる可能性があります。
slm

1
@slm:良い点。思い出させてくれてありがとう。ただし、明日はこれを行います。またstrace、コンテナ内で制限されている可能性もあります。学ぶためのエキサイティングな新しいもの。アイデアをバウンスしていただきありがとうございます。しかし、ベッドを打つ必要があります。
0xC0000022L

参考:これもnetstat -lpを壊します。それは間違いなく防具によって引き起こされます。
アランロバートソン14

回答:


7

(注:それはアスカーがドッキングウィンドウコンテナに入っているか疑問では不明である私がしています。仮定 docker exec -it CONTAINER bashを使用しました。)

centos:7Dockerバージョンに基づいたDockerイメージを使用するときにこの問題が発生しましたが、1.9.0これを克服するために実行しました:

docker exec --privileged -it CONTAINER bash

を含めることに注意してください--privileged

これが必要な理由についての私の素朴な理解:ここに文書化されているように、Dockerはコンテナをより「安全」にする努力をしているようです


4

ハハ、プロットが厚くなっています。誰かがより良い答えを持っている場合、それを書いてください、そして、許容できるならば、私はそれを受け入れます。しかし、ここで明らかな理由。ホスト上のログファイルを無視するのは私にとってどれほど怠慢なのでしょうか。

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"

そのため、防具が犯人のように見えますが、ホスト/コンテナのセキュリティを損なうことなくこれを許可するか、セキュリティを損なうことなくそれが可能かどうかを確認する方法を見つけ出す必要があります。




2

私もこの問題を発見しました。を無効apparmorにすると問題はなくなりましたdocker

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

参照URL:https : //help.ubuntu.com/community/AppArmor


3
この回答にさらに説明を追加することを検討することをお勧めします(たとえば、何をaa-complain行うか、このソリューションをサポートするドキュメントなど)。
HalosGhost 14

@HalosGhost申し訳ありませんが、私はあまり詳しくないので、グーグルで検索apparmorして無効にする方法を見つけました。つまり、なぜ機能するのか、なぜ機能しなかったのかがわかりません。私のホストosはUbuntu 14.04であるため、「ubuntu apparmor」を検索し、help.ubuntu.com / community / AppArmorを見つけました。これがあなたのお役に立てば幸いです。
メンガン14

2
この問題はありません。私の懸念は、あなたの答えの質と、それがOPにとってどれほど役立つ(そして有益な)かということでした。
HalosGhost 14

@HalosGhostあなたの助けをありがとう、私は私の答えを再編集します。
メンガン14

Ubuntu 14.04では、コマンドはでしたsudo aa-complain /etc/apparmor.d/docker。基本的には、Dockerプロセスのアプリアーマーを無効にします。つまり、Dockerはシステム上の任意のファイルを読み取ることができます。以前は、プロファイルで許可されたファイルでのみ機能しました。より良い解決策は、/ proc / pid / fdファイルへのアクセスを許可するアプリのアーマールールを変更することです。
マーティンズバロディス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.