[lxc-users] permissions question: netstat -anp does not show process for non owned processes

[Eric W. Biederman]

Serge Hallyn <serge.hallyn at ubuntu.com> writes:

> So running a netstat as ubuntu user in the container and stracing netstat, the
> only eaccess I got was:
>
> 492   open("/proc/90/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)
> 492   open("/proc/95/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)
> 492   open("/proc/97/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)
> 492   open("/proc/462/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)
> 492   open("/proc/464/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)
>
>
> those tasks are:
> daemon      90     1  0 17:12 ?        00:00:00 /usr/sbin/atd -f
> syslog      95     1  0 17:12 ?        00:00:00 /usr/sbin/rsyslogd -n
> message+    97     1  0 17:12 ?        00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
> root       462   452  0 17:13 ?        00:00:00 su - ubuntu
> ubuntu     464   463  0 17:13 ?        00:00:00 (sd-pam)
>
> interesting.
>
> It doesn't appear to be yama - setting ptrace_scope -t 0 doesn't help.
>
> /proc/90/fd is owned by nobody:nogroup in the container, root:root on
> the host.
>
> Looking at the code in fs/proc/base.c, it seems the code intends to
> use the cred of the task to which the procpid entry belongs.  So it
> really should be owned by daemon.
>
> (proc_tgid_lookup should be called, iiuc, to fill in the details about fd
> under /proc/pid, it gets the task to which /proc/pid belongs, passes that
> to proc_pident_instantiate, which passes it to proc_pid_make_inode, which
> gets the task cred uid/gid and assigns them to the inode)
>
> I'm sure there's a good reason for this, but i'm failing to remember what
> it is.

This is the dumpable restriction.  When a processes changes it's creds
in the right way it stops being dumpable.  Currently dumpable is a very
simple global thing, not a user namespace isolated thing.

We have talked about sorting this out but it has never been on the top
of anyone's list to do.

To make this work I think we need dumpable to change to an indication of
which user namespace root we can allow to dump a file.

Eric