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

[Serge E. Hallyn]

Quoting Eric W. Biederman (ebiederm at xmission.com):
> 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.

Oh.  I guess my vague memories of talking about those somehow made me
think we'd handled it long ago.

> 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.

I'm surprised there haven't been more complaints about this :)

Wonder whether we'll get any volunteers to work on it...

thanks,
-serge