From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72582 invoked by alias); 1 May 2015 13:18:24 -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 72563 invoked by uid 89); 1 May 2015 13:18:23 -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-f44.google.com Received: from mail-oi0-f44.google.com (HELO mail-oi0-f44.google.com) (209.85.218.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 01 May 2015 13:18:22 +0000 Received: by oiko83 with SMTP id o83so69784834oik.1 for ; Fri, 01 May 2015 06:18:20 -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=Z59AGnkDWt/WTIy0osakzeJQXdFabytwIw2Uv9edrm0=; b=EslqG/kC4lGGAcu+utBQAQ8GBFOupx0L0p9NSTVKwuRUMm8+Bb2R37EFB+HTFWLf0Z PHMyoQNXn6Ryf8xWPndrgQQbaqbJmWQjqKoX4ohgl2Rru3/jYyqchidR0aKBcc8q+mnx uUdNmm6A9QKa6zfx6+cS7Eil1ptMZQJL3T92sj5kMhdHgOUKDF+WcNkTg43YBh/vting 34jHtLFxB+vh+fAIbj62ylK6VxDkBSUzrpJrm8wcd3PZ0UIXJ/Pp+9EgcZQgb5JrI4F9 9t35Jan+cl7fAMnN48hw7fAB4EX+hZ5TIuZgRfq7GXd1y+yAJFoN6eSKlZMoFzk9dxER onJQ== X-Gm-Message-State: ALoCoQlh9LL6lb9Jy/fggEBW/gPau8VoFB6M0ll5FHG7Vwd9s+jCdg1TY1y6kFyBmFfnh9yUFDQE MIME-Version: 1.0 X-Received: by 10.202.84.135 with SMTP id i129mr7229543oib.114.1430486300398; Fri, 01 May 2015 06:18:20 -0700 (PDT) Received: by 10.60.76.232 with HTTP; Fri, 1 May 2015 06:18:20 -0700 (PDT) In-Reply-To: <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> <20150501092817.GA28105@blade.nx> Date: Fri, 01 May 2015 13:18: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/msg00001.txt.bz2 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. > 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? > 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.) Thanks for the explanation. Cheers, Alban > Cheers, > Gary > > -- > http://gbenson.net/