Làm cách nào tôi có thể thay thế lsof bên trong Docker (bản địa, không dựa trên LXC)


16

Tôi hơi khó hiểu rằng bên trong một Docker container lsof -ikhông mang lại bất kỳ đầu ra nào.

Ví dụ (tất cả các lệnh / đầu ra từ bên trong container):

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

Cũng xin lưu ý làm thế nào không có tên chương trình hoặc tên chương trình được hiển thị bởi netstat. fusercũng cung cấp đầu ra hơi khó hiểu và cũng không thể xác định chính xác các PID.

bất cứ ai có thể rụng bất kỳ ánh sáng về điều này?

  • Làm thế nào tôi có thể thay thế lsof -i(để xem tên quá trình là tốt!)
  • Tại sao đầu ra của netstatquè là tốt?

NB: Container chạy với "ExecDriver": "native-0.1", đó là lớp thực thi riêng của Docker, không phải 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:

(Tôi không bị ám ảnh bởi Permission denied, bởi vì những con số đó. Điều khiến tôi bối rối là danh sách trống của các PID sau 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)

Có một số đầu ra nữa cho người dùng được kết nối, cũng được xác định chính xác, nhưng đó là nó. Rõ ràng là không thể phân biệt được loại nào ( lsof -igiới hạn đối với ổ cắm internet) một "đối tượng" nhất định.


Một làm những gì lsofbáo cáo? Giống nhau?
slm

@slm: cuộc điều tra tuyệt vời! Nó không giữ nó trống. Thay vào đó, nó hiển thị một loạt các dòng (cũng sshdliên quan), một số trong đó có thể là ổ cắm TCP, như TYPE unknown. Kỳ lạ. Áp dụng đầu ra cho câu hỏi của tôi.
0xC0000022L

Nếu bạn chạy, strace -s 2000 -o lsof.log lsof -inó có thể sẽ cung cấp cho bạn một số hiểu biết bổ sung về những gì bị chặn.
slm

1
@slm: điểm tốt. Cảm ơn vì đã nhắc tôi. Tôi sẽ làm điều này vào ngày mai, mặc dù. Cũng có thể là stracechính nó được giới hạn trong container. Công cụ mới thú vị để tìm hiểu. Cảm ơn cho ý tưởng nảy. Phải đánh giường, mặc dù.
0xC0000022L

FYI: Điều này cũng phá vỡ netstat -lp. Nó chắc chắn được gây ra bởi apparmor.
Alan Robertson

Câu trả lời:


7

(LƯU Ý: không rõ ràng trong câu hỏi làm thế nào người hỏi vào container docker. Tôi giả sử docker exec -it CONTAINER bash đã được sử dụng.)

Tôi gặp vấn đề này khi sử dụng hình ảnh docker dựa trên centos:7phiên bản docker 1.9.0và để khắc phục điều này, tôi chỉ chạy:

docker exec --privileged -it CONTAINER bash

Lưu ý bao gồm --privileged.

Sự hiểu biết ngây thơ của tôi về lý do này là bắt buộc: có vẻ như docker nỗ lực để container được "an toàn" hơn, như được ghi lại ở đây .


4

Hah, cốt truyện dày lên. Nếu ai đó có câu trả lời tốt hơn xin vui lòng viết nó lên và tôi sẽ chấp nhận nó, nếu được chấp nhận. Nhưng đây là lý do rõ ràng. Làm thế nào sơ suất của tôi để bỏ qua các tập tin nhật ký trên máy chủ :

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"

Vì vậy, apparmor dường như là thủ phạm, mặc dù tôi sẽ phải tìm ra cách thuyết phục nó cho phép điều này mà không ảnh hưởng đến an ninh máy chủ / container hoặc xem liệu có khả thi mà không ảnh hưởng đến an ninh hay không.


2
Được mô tả trong vấn đề Docker # 7276
Anthony O.

3

Một khả năng khác, lần này với cài đặt bảo mật được tăng cường hơn: cung cấp đặc quyền SYS_PTRACE cho bộ chứa docker:

docker run --cap-add=SYS_PTRACE ...

1
Trong trường hợp bất cứ ai thắc mắc tại sao lsofcần CAP_SYS_PTRACE: Nó bắt buộc phải đọc /proc/*/stat. Xem ptrace (2)
David Röthlisberger

2

Tôi đã tìm thấy vấn đề này quá. Vấn đề đã đi sau khi tôi bị vô hiệu hóa apparmortrên docker:

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

url tham chiếu: https://help.ubfox.com/community/AppArmor


3
Bạn có thể muốn xem xét thêm giải thích cho câu trả lời này (ví dụ: cái gì aa-complainhoặc một số tài liệu hỗ trợ giải pháp này).
HalosGhost

@HalosGhost Xin lỗi, tôi không quen lắm apparmor, tôi chỉ tìm hiểu và tìm cách vô hiệu hóa nó. Nói cách khác, tôi không biết tại sao nó hoạt động hoặc tại sao nó không hoạt động. Hệ điều hành máy chủ lưu trữ của tôi là Ubuntu 14.04, vì vậy tôi đã tìm kiếm "ub Ubuntu apparmor" và tìm thấy help.ubfox.com/community/AppArmor . Tôi hy vọng điều này sẽ hữu ích cho bạn.
menghan

2
Tôi không có vấn đề này; mối quan tâm của tôi là về chất lượng câu trả lời của bạn và mức độ hữu ích (và thông tin) của OP đối với OP.
HalosGhost

@HalosGhost Cảm ơn sự giúp đỡ của bạn, tôi xác nhận lại câu trả lời của tôi.
menghan

Trên Ubuntu 14.04 lệnh đã được sudo aa-complain /etc/apparmor.d/docker. Về cơ bản, nó vô hiệu hóa áo giáp ứng dụng cho quá trình docker, điều đó có nghĩa là docker có thể đọc bất kỳ tập tin nào trên hệ thống. Trước đây nó chỉ có thể hoạt động với các tệp được cho phép trong hồ sơ. Một giải pháp tốt hơn có thể là thay đổi các quy tắc áo giáp ứng dụng cho phép truy cập vào các tệp / Proc / pid / fd.
Martins Balodis
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.