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

[Alban Crequy <alban@endocode.com>]

On Fri, May 1, 2015 at 1:29 PM, Gary Benson <gbenson@redhat.com> wrote:
> Alban Crequy wrote:
>> 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.
>
> Interesting... how'd you get the user IDs to line up?

I just tested by manually writing in /etc/passwd in the container.

>> > 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?
>
> It's the PID on the host, I've just been finding them with ps.

But if you get the pid of the process to debug on the host, that pid
is not meaningful in the container where GDB is running. How can tell
gdb to attach to the pid if that pid is not visible in gdb's
container?

> I'm
> not sure how well that'd work if you had hundreds or thousands of
> containers running though...  It'd be nice to have a command like ps
> but that was limited to one container and that listed both inner and
> outer PIDs, but I don't think any exist.  I don't think the kernel
> even exports any way to translates PIDs from one PID namespace to
> another... there were some patches back in November but I don't think
> they got in.
>
>> > > 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.
>
> No worries.  FWIW I expect you probably can access /proc/PID/root if
> you're running with the same UID like you seem to be, but the symlink
> issue is still there.
>
> Cheers,
> Gary
>
> --
> http://gbenson.net/