From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104094 invoked by alias); 1 May 2015 20:29:56 -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 103394 invoked by uid 89); 1 May 2015 20:29:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 01 May 2015 20:29:54 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t41KTo03024679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 1 May 2015 16:29:50 -0400 Received: from blade.nx (ovpn-116-76.ams2.redhat.com [10.36.116.76]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t41KTn0u032174; Fri, 1 May 2015 16:29:49 -0400 Received: by blade.nx (Postfix, from userid 1000) id 900B2263E7D; Fri, 1 May 2015 21:29:48 +0100 (BST) Date: Fri, 01 May 2015 20:29:00 -0000 From: Gary Benson To: Alban Crequy Cc: gdb-patches@sourceware.org, Eli Zaretskii , Pedro Alves , Doug Evans , Iago =?iso-8859-1?Q?L=F3pez?= Galeiras Subject: Re: [PATCH 2/9 v2] Introduce nat/linux-namespaces.[ch] Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00012.txt.bz2 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? > > 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. 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/