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

[Gary Benson <gbenson at redhat dot com>]

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.

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.

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

Cheers,
Gary

-- 
http://gbenson.net/