From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73739 invoked by alias); 1 May 2015 09:28:29 -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 73725 invoked by uid 89); 1 May 2015 09:28:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham 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 09:28:27 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t419SMWO000971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 1 May 2015 05:28:22 -0400 Received: from blade.nx (ovpn-116-76.ams2.redhat.com [10.36.116.76]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t419SKS7005348; Fri, 1 May 2015 05:28:21 -0400 Received: by blade.nx (Postfix, from userid 1000) id E8BB7263E41; Fri, 1 May 2015 10:28:17 +0100 (BST) Date: Fri, 01 May 2015 09:28: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: <20150501092817.GA28105@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150501000739.740.47967@domU-12-31-39-0A-A0-4F> X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00000.txt.bz2 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. 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//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/