Jestem nieco zaskoczony, że wewnątrz kontenera Docker lsof -inie daje żadnych wyników.
Przykład (wszystkie polecenia / dane wyjściowe z kontenera):
[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 -
Zwróć także uwagę, jak nie wyświetla się żaden PID ani nazwa programu netstat. fuserdaje również nieco mylące dane wyjściowe i nie jest również w stanie wskazać PID.
Czy ktoś może rzucić jakieś światło na ten temat?
- Jak mogę podstawić
lsof -i(aby zobaczyć również nazwę procesu !) - Dlaczego produkcja jest również
netstatkaleką?
NB: Kontener działa z "ExecDriver": "native-0.1", czyli własną warstwą wykonawczą Dockera, a nie 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:
(Nie mam obsesji na punkcie tego Permission denied, ponieważ te liczby. To, co mnie dezorientuje, to pusta lista PID po 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)
Podłączony użytkownik ma jeszcze więcej danych wyjściowych, które również są poprawnie zidentyfikowane, ale to wszystko. Najwyraźniej nie można rozpoznać, jakiego typu ( lsof -iograniczenia gniazd internetowych) jest pewien „obiekt”.
źródło
lsofraport? To samo?sshdpowiązanych) linii, z których niektóre mogą być gniazdami TCP, jakTYPEunknown. Szczególny. Dołączanie wyniku do mojego pytania.strace -s 2000 -o lsof.log lsof -i, prawdopodobnie dostarczysz dodatkowych informacji o tym, co jest blokowane.stracesam jest ograniczony w pojemniku. Ekscytujące nowe rzeczy do nauki. Dzięki za odrzucony pomysł. Ale musi trafić w łóżko.Odpowiedzi:
(UWAGA: nie jest jasne, w jaki sposób pytający wchodzi do kontenera dokowanego. Zakładam, że
docker exec -it CONTAINER bashzostał użyty).Miałem ten problem, gdy korzystałem z obrazu dokera opartego na
centos:7wersji dokera1.9.0i aby go rozwiązać, po prostu uruchomiłem:docker exec --privileged -it CONTAINER bashZwróć uwagę na włączenie
--privileged.Moje naiwne zrozumienie powodu, dla którego jest to wymagane: wydaje się, że doker stara się, aby kontener był bardziej „bezpieczny”, jak tu udokumentowano .
źródło
Hah, fabuła gęstnieje. Jeśli ktoś ma lepszą odpowiedź, proszę ją napisać, a ja ją zaakceptuję, jeśli będzie to możliwe. Ale tutaj oczywisty powód. Jak zaniedbanie mojego zignorowania plików dziennika na hoście :
Sprawca wydaje się więc winowajcą, chociaż muszę wymyślić, jak go przekonać, aby na to pozwolić, bez narażania bezpieczeństwa hosta / kontenera, lub sprawdzania, czy jest to w ogóle możliwe bez narażania bezpieczeństwa.
źródło
Inna możliwość, tym razem z bardziej szczegółowymi ustawieniami zabezpieczeń: nadaj SYS_PTRACE uprawnienie kontenerowi dokowanemu:
źródło
lsofpotrzebujeCAP_SYS_PTRACE: należy przeczytać/proc/*/stat. Zobacz ptrace (2)Znalazłem też ten problem. Problem upadł po tym wyłączona
apparmornadocker:referencyjny adres URL: https://help.ubuntu.com/community/AppArmor
źródło
aa-complainjest lub trochę dokumentacji, która obsługuje to rozwiązanie).apparmor, po prostu google go i znalazłem sposób, aby go wyłączyć. Innymi słowy, nie wiem, dlaczego to działa lub dlaczego nie działa. Moim hostem jest Ubuntu 14.04, więc szukałem „ubuntu apparmor” i znalazłem help.ubuntu.com/community/AppArmor . Mam nadzieję, że to ci pomoże.sudo aa-complain /etc/apparmor.d/docker. Zasadniczo wyłącza zbroję aplikacji dla procesu dokera, co oznacza, że doktor może odczytać dowolny plik w systemie. Wcześniej mogło działać tylko z plikami dozwolonymi w profilu. Lepszym rozwiązaniem może być zmiana reguł pancerza aplikacji, które zezwalają na dostęp do plików / proc / pid / fd.