哪个 PID 在没有网络工具的情况下使用 k8s pod 内的 PORT

Question

Sorry about the long question post, but I think it can be useful to others to learn how this works.

What I know:

On any linux host ( not using docker container ), I can look at /proc/net/tcp to extract information tcp socket related.

So, I can detect the ports in LISTEN state with:

cat /proc/net/tcp | 
 grep " 0A " | 
  sed 's/^[^:]*: \(..\)\(..\)\(..\)\(..\):\(....\).*/echo $((0x\4)).$((0x\3)).$((0x\2)).$((0x\1)):$((0x\5))/g' | 
   bash

Results:

0.0.0.0:111
10.174.109.1:53
127.0.0.53:53
0.0.0.0:22
127.0.0.1:631
0.0.0.0:8000

/proc/net/tcp gives UID , GID , unfortunately does not provides the PID . But returns the inode . That I can use to discover the PID using it as file descriptor.

So one way is to search /proc looking for the inode socket. It's slow, but works on host:

cat /proc/net/tcp |
 grep " 0A " |
  sed 's/^[^:]*: \(..\)\(..\)\(..\)\(..\):\(....\).\{72\}\([^ ]*\).*/echo $((0x\4)).$((0x\3)).$((0x\2)).$((0x\1)):$((0x\5))\\\t$(find \/proc\/ -type d -name fd 2>\/dev\/null \| while read f\; do ls -l $f 2>\/dev\/null \| grep -q \6 \&\& echo $f; done)/g' |
   bash

output:

0.0.0.0:111     /proc/1/task/1/fd /proc/1/fd /proc/924/task/924/fd /proc/924/fd
10.174.109.1:53 /proc/23189/task/23189/fd /proc/23189/fd
127.0.0.53:53   /proc/923/task/923/fd /proc/923/fd
0.0.0.0:22      /proc/1194/task/1194/fd /proc/1194/fd
127.0.0.1:631   /proc/13921/task/13921/fd /proc/13921/fd
0.0.0.0:8000    /proc/23122/task/23122/fd /proc/23122/fd

Permission tip 1: You will only see what you have permission to look at.

Permission tip 2: fake root used in containers does not have access to all file descriptors in /proc/*/fd . You need to query it for each user.

If you run as normal user the results are:

0.0.0.0:111
10.174.109.1:53
127.0.0.53:53
0.0.0.0:22
127.0.0.1:631
0.0.0.0:8000    /proc/23122/task/23122/fd /proc/23122/fd

Using unshare to isolate environment it works as expected:

$ unshare -r --fork --pid unshare -r --fork --pid --mount-proc -n bash
# ps -fe
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  2 07:19 pts/6    00:00:00 bash
root       100     1  0 07:19 pts/6    00:00:00 ps -fe
# netstat -ntpl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
# python -m SimpleHTTPServer &
[1] 152
# Serving HTTP on 0.0.0.0 port 8000 ...
netstat -ntpl
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:8000            0.0.0.0:*               LISTEN      152/python          
# cat /proc/net/tcp |
>  grep " 0A " |
>   sed 's/^[^:]*: \(..\)\(..\)\(..\)\(..\):\(....\).\{72\}\([^ ]*\).*/echo $((0x\4)).$((0x\3)).$((0x\2)).$((0x\1)):$((0x\5))\\\t$(find \/proc\/ -type d -name fd 2>\/dev\/null \| while read f\; do ls -l $f 2>\/dev\/null \| grep -q \6 \&\& echo $f; done)/g' |
>    bash
0.0.0.0:8000    /proc/152/task/152/fd /proc/152/fd
# ls -l /proc/152/fd
total 0
lrwx------ 1 root root 64 mai 25 07:20 0 -> /dev/pts/6
lrwx------ 1 root root 64 mai 25 07:20 1 -> /dev/pts/6
lrwx------ 1 root root 64 mai 25 07:20 2 -> /dev/pts/6
lrwx------ 1 root root 64 mai 25 07:20 3 -> 'socket:[52409024]'
lr-x------ 1 root root 64 mai 25 07:20 7 -> /dev/urandom
# cat /proc/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 00000000:1F40 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 52409024 1 0000000000000000 100 0 0 10 0 

Inside a docker container in my host, it seems to work in same way.

The problem:

I have a container inside a kubernetes pod running jitsi. Inside this container, I am unable to get the PID of the service listening the ports.

Nor after installing netstat:

root@jitsi-586cb55594-kfz6m:/# netstat -ntpl
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:5222            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:5269            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:5280            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:5347            0.0.0.0:*               LISTEN      -                   
tcp6       0      0 :::5222                 :::*                    LISTEN      -                   
tcp6       0      0 :::5269                 :::*                    LISTEN      -                   
tcp6       0      0 :::5280                 :::*                    LISTEN      -                   

# ps -fe
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 May22 ?        00:00:00 s6-svscan -t0 /var/run/s6/services
root        32     1  0 May22 ?        00:00:00 s6-supervise s6-fdholderd
root       199     1  0 May22 ?        00:00:00 s6-supervise jicofo
jicofo     203   199  0 May22 ?        00:04:17 java -Xmx3072m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/ -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=config -Djava
root      5990     0  0 09:48 pts/2    00:00:00 bash
root     10926  5990  0 09:57 pts/2    00:00:00 ps -fe

Finally the Questions:

a) Why can't I read the file descriptors of the proccess listening port 5222?

root@jitsi-586cb55594-kfz6m:/# cat /proc/net/tcp | grep " 0A "
    0: 00000000:1466 00000000:0000 0A 00000000:00000000 00:00000000 00000000   101        0 244887827 1 ffff9bd749145800 100 0 0 10 0                 
...
root@jitsi-586cb55594-kfz6m:/# echo $(( 0x1466 ))
5222
root@jitsi-586cb55594-kfz6m:/# ls -l  /proc/*/fd/* 2>/dev/null | grep 244887827                                                     
root@jitsi-586cb55594-kfz6m:/# echo $?
1
root@jitsi-586cb55594-kfz6m:/# su - svc
svc@jitsi-586cb55594-kfz6m:~$ id -u
101
svc@jitsi-586cb55594-kfz6m:~$ ls -l /proc/*/fd/* 2>/dev/null | grep 244887827
svc@jitsi-586cb55594-kfz6m:~$ echo $?
1

b) There is another way to list inode and link it to a pid without searching /proc/*/fd ?

Update 1:

Based on Anton Kostenko tip, I looked to AppArmor. It's not the case because the server don't use AppArmor, but searching, took me to SELinux.

In a ubuntu machine where AppArmor is running, I got:

$ sudo apparmor_status  | grep dock                                                                              
   docker-default

In the OKE(Oracle Kubernetes Engine, my case) node there is no AppArmor. I got SELinux instead:

$ man selinuxenabled | grep EXIT -A1
EXIT STATUS
       It exits with status 0 if SELinux is enabled and 1 if it is not enabled.
$ selinuxenabled && echo $?
0

Now, I do believe that SELinux is blocking the /proc/*/fd listing from root inside the container. But I don't know yet how to unlock it.

References:

https://jvns.ca/blog/2016/10/10/what-even-is-a-container/

Answer 1

The issue is solved by adding the POSIX capability: CAP_SYS_PTRACE

I'm my case the container are under kubernetes orchestration.

this reference explains about kubectl and POSIX Capabilities

So I have

root@jitsi-55584f98bf-6cwpn:/# cat /proc/1/status | grep Cap
CapInh: 00000000a80425fb
CapPrm: 00000000a80425fb
CapEff: 00000000a80425fb
CapBnd: 00000000a80425fb
CapAmb: 0000000000000000

So I careful read the POSIX Capabilities Manual . But even adding CAP_SYS_ADMIN , the PID does not appear on netstat . So I tested all capabilities. CAP_SYS_PTRACE is The Chosen One

root@jitsi-65c6b5d4f7-r546h:/# cat /proc/1/status | grep Cap
CapInh: 00000000a80c25fb
CapPrm: 00000000a80c25fb
CapEff: 00000000a80c25fb
CapBnd: 00000000a80c25fb
CapAmb: 0000000000000000

So here my deployment spec change:

...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
        ...
        securityContext:
          capabilities:
            add:
            - SYS_PTRACE
...

Yet I don't know what security reasons selinux use to do it. But for now it's good enough for me.

References:

• https://man7.org/linux/man-pages/man7/capabilities.7.html
• https://kubernetes.io/docs/tasks/configure-pod-container/security-context/