Re: [PATCH 2/9 v2] Introduce nat/linux-namespaces.[ch]

[Alban Crequy <alban at endocode dot com>]

On Fri, May 1, 2015 at 11:28 AM, Gary Benson <gbenson@redhat.com> wrote:
>
> Alban Crequy wrote:
> > On Thu, Apr 30, 2015 at 2:05 PM, Gary Benson <gbenson@redhat.com> wrote:
> > > This commit introduces new shared files nat/linux-namespaces.[ch]
> > > containing code to support Linux namespaces that will be used by
> > > both GDB and gdbserver.
> >
> > Thanks for working on this!
> >
> > > +/* We need to use setns(2) to handle filesystem access in mount
> > > +   namespaces other than our own, but this isn't permitted for
> > > +   multithreaded processes.  GDB is multithreaded when compiled
> > > +   with Guile support, and may become multithreaded if compiled
> > > +   with Python support.  We deal with this by spawning a single-
> > > +   threaded helper process to access mount namespaces other than
> > > +   our own.
> >
> > setns() needs CAP_SYS_CHROOT and CAP_SYS_ADMIN to change the mnt
> > namespace.  So users will need to run gdb as root...
>
> As root, or with those privileges yes.  But if you're attaching to
> a process in a container, it's not running as the same UID as you;
> you have to have CAP_SYS_PTRACE, for example, to even get to the
> point where GDB wants to access the files.

Ok, I understand the scenario.

I had tried only with a non-root process in the container and gdb on
the host with the same uid, so I didn't need CAP_SYS_PTRACE. But
that's probably not a good use case.

> The scenario I'm targeting is that you have an application you want
> to debug running in a container.  You don't want to run GDB as root
> on the container host, so you start a second container with just the
> privileges you need and run GDB from there.

How do you get the pid of the process to give as a parameter to "gdb
-p" if gdb is running in a different pid namespace than the process to
debug?

> I've been testing this with Docker, which has --cap-add and --cap-drop
> options to adjust what privileges containers are granted when they are
> created with "docker run".  I'm assuming other containering systems
> have something similar.
>
> > Would accessing the files directly through
> > /proc/<pid_of_traced_process>/root/usr/lib/debug/... work, without
> > needing the superuser? If it works, it would also remove the
> > requirement for the single-threaded helper process.
>
> No, you need to be root (or have CAP_DAC_OVERRIDE or something) to
> access /proc/PID/root.  There's also issues with symlinks pointing
> back to / if you access the files that way.  I investigated it back
> in February and I don't think you can handle paths with symlinks in
> a way that's 100% race-free.  (I've not been overly concerned with
> security but I didn't want to introduce a way for a hostile app to
> exploit GDB to break out of its container.)

Thanks for the explanation.

Cheers,
Alban

> Cheers,
> Gary
>
> --
> http://gbenson.net/