ownership of /proc/1/* is root even the user is non-root

[sedflix]

Issue

When tini binary is owned by root:root, the ownership of most content inside /proc/1* is also root:root even though some other user(app:app) executed the tini process.
If we change the ownership of the process to app:app, the ownership of content inside /proc/1* will be as app:app` as expected.

Example Dockerfile / Output

FROM oraclelinux:8

# download tini
ENV TINI_VERSION v0.19.0
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini
RUN chmod +x /tini


# create group and user
RUN groupadd -g 2001 -o app
RUN useradd -m -u 1001 -g 2001 -o -s /bin/bash app


#RUN chown 1001:2001 /tini

USER 1001:2001

ENTRYPOINT ["/tini", "-vvvvv", "--"]
CMD ["ls","-l","/proc/1"]

[INFO  tini (1)] Spawned child process 'ls' with pid '7'
ls: cannot read symbolic link '/proc/1/cwd': Permission denied
ls: cannot read symbolic link '/proc/1/root': Permission denied
ls: cannot read symbolic link '/proc/1/exe': Permission denied
total 0
-r--r--r--  1 root root 0 Sep  1 11:48 arch_status
dr-xr-xr-x  2 app  app  0 Sep  1 11:48 attr
-rw-r--r--  1 root root 0 Sep  1 11:48 autogroup
-r--------  1 root root 0 Sep  1 11:48 auxv
-r--r--r--  1 root root 0 Sep  1 11:48 cgroup
--w-------  1 root root 0 Sep  1 11:48 clear_refs
-r--r--r--  1 root root 0 Sep  1 11:48 cmdline
-rw-r--r--  1 root root 0 Sep  1 11:48 comm
...

I'm not able to understand why the owner ship of most of the content here is root.

[krallin]

Tini doesn't do anything special with those files (nor does it create them), so I'm not sure there's much I can help you with here. Have you double-checked what user Tini is running as?

I'd also advise doing a little research on this, e.g. this might be relevant to you:

https://unix.stackexchange.com/questions/75045/files-in-proc-pid-e-g-ssh-agent-chrome-are-not-owned-by-user-but-by-root

[sedflix]

@krallin thanks for the quick response.

yeah, tini doesn't create any of these files and this issue is not exactly a fault in tini code.

But it does call syscalls/calls that play around with several core process attributes(prctl,setpgid, tcsetpgrp) which could unintentionally result in this. I'm not really sure which call is resulting in this issue.

I tried using ENTRYPOINT ["sleep", "36000"] and in this particular case everything in /proc/1/* had the ownership of app:app even though sleep is owned by root:root.

/proc/sys/fs/suid_dumpable remains 0 throughout the process.

[sedflix]

Played around a bit more and tried to find the differences between "sleep" and "tini" executable.
Apparently, sleep binary had "go+r" permission, and tini binary had "go-r". It was all because of the read permissions and had nothing to do with tini as you mentioned before.