I don't use docker myself, but if we are speaking about CONFIG_GRKERNSEC_PROC_USER and CONFIG_GRKERNSEC_PROC_USERGROUP, it would be important to know what GID is specified in CONFIG_GRKERNSEC_PROC_GID? That GID is an exception and can provide a way to let that group bypass CONFIG_GRKERNSEC_PROC_USER restrictions. I could successfully find the proper settings when I converted to systemd - although I had enough, so I'm using openrc for some time now. So if you can figure out the important process's GID, you can officially circumwent the restrictions. Too bad if the incriminated process runs as root... If you can influence with what GID the important process starts, you have a key for a solution. -- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057
2017.Szeptember 8.(P) 21:20 időpontban Alex Efros ezt írta: > Hi! > > It looks like when connecting to existing docker container with `docker > exec` CONFIG_GRKERNSEC_PROC_USERGROUP (and probably > CONFIG_GRKERNSEC_PROC_USER too) hide processes started by `docker run` > from processes started by `docker exec` (all processes are running as > docker "root", docker daemon is started with default options, i.e. without > --userns-remap). > > Why is this happens and is there any workaround? > > > $ sudo zgrep GRKERNSEC_PROC_USER /proc/config.gz > # CONFIG_GRKERNSEC_PROC_USER is not set > CONFIG_GRKERNSEC_PROC_USERGROUP=y > > $ docker run -d -it --rm --init alpine sh -c 'ps ax; exec sleep 42' > 49bec4451495563d702ad0edb9a7c80a9a7f5918fab4eb67e5a44b803f3ac656 > > $ docker logs 49bec4451495 > PID USER TIME COMMAND > 1 root 0:00 /dev/init -- sh -c ps ax; exec sleep 42 > 7 root 0:00 sh -c ps ax; exec sleep 42 > 8 root 0:00 ps ax > > $ docker exec -it 49bec4451495 ps ax > PID USER TIME COMMAND > 9 root 0:00 ps ax > > -- > WBR, Alex. >
