From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70693 invoked by alias); 6 May 2015 18:55:02 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 70682 invoked by uid 89); 6 May 2015 18:55:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-oi0-f47.google.com Received: from mail-oi0-f47.google.com (HELO mail-oi0-f47.google.com) (209.85.218.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 06 May 2015 18:55:00 +0000 Received: by oign205 with SMTP id n205so15287235oig.2 for ; Wed, 06 May 2015 11:54:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wRhU033goRtIHwaU8naDrgxQ1uXt2AKko7TTf/T22D4=; b=jfa5ovXdR/EIgESOWvAOqhjy410+uAAa7dtbdWZP4oZq7A7fI02uxVQr4qClHslGgu I82H0OJhUlmINaLEZREx/Yb+2LyiIZG85YKcbbcG4YyKUcwb+Bj6b5tDb/FTq3PSDw6k FfK2SCz56Gmd8dNc87p8D4tulJ3ppcNwvTJEkncTNNcL+FUpUwmbGAzaylB1cFd/NYfS PzzAHGIGQ5LBUsThnIAuB2aVypKyng6csdXtAWEe/O6+iyak7LSnJXyTMUkfxdakq8mf mQFUmmi1QMnryKG4gKqKyVhHIYI1U971XtT0G1siS+UbXA/mq09fY9qbuP7pxg+AfcXX q64Q== X-Gm-Message-State: ALoCoQlo+sy1uhXtMTmbaUme+0z/Pf85Lyea0r3/VngjJklFluEn4jUvHKIXzLilidgNwPyXPfuf MIME-Version: 1.0 X-Received: by 10.182.70.100 with SMTP id l4mr101095obu.77.1430938497939; Wed, 06 May 2015 11:54:57 -0700 (PDT) Received: by 10.60.76.232 with HTTP; Wed, 6 May 2015 11:54:57 -0700 (PDT) In-Reply-To: <20150501202948.GA11582@blade.nx> References: <1429186791-6867-1-git-send-email-gbenson@redhat.com> <1430395542-16017-3-git-send-email-gbenson@redhat.com> <20150501000739.740.47967@domU-12-31-39-0A-A0-4F> <20150501092817.GA28105@blade.nx> <20150501202948.GA11582@blade.nx> Date: Wed, 06 May 2015 18:55:00 -0000 Message-ID: Subject: Re: [PATCH 2/9 v2] Introduce nat/linux-namespaces.[ch] From: Alban Crequy To: Gary Benson Cc: gdb-patches@sourceware.org, Eli Zaretskii , Pedro Alves , Doug Evans , =?UTF-8?Q?Iago_L=C3=B3pez_Galeiras?= Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00125.txt.bz2 On Fri, May 1, 2015 at 1:29 PM, Gary Benson wrote: > Alban Crequy wrote: >> On Fri, May 1, 2015 at 11:28 AM, Gary Benson wrote: >> > Alban Crequy wrote: >> > > On Thu, Apr 30, 2015 at 2:05 PM, Gary Benson 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//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/