From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47953 invoked by alias); 19 Aug 2019 14:57:17 -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 47938 invoked by uid 89); 19 Aug 2019 14:57:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=(unknown) X-HELO: mail-lf1-f65.google.com Received: from mail-lf1-f65.google.com (HELO mail-lf1-f65.google.com) (209.85.167.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Aug 2019 14:57:15 +0000 Received: by mail-lf1-f65.google.com with SMTP id s19so1627108lfb.9 for ; Mon, 19 Aug 2019 07:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2xUuPJbB8RfAFmZ94NJxHHxrlhknTGlYdth/3Qr7Z/g=; b=Pr/NHPxWdsN1Tp/tE3yjLZWj7rm/vUvIabYsw+82kf4jMsFLchEwTpzt2mUhu8FpWE ak64ArarYC5gHXWQSqG9Kh7R4mUZ+iniRcT5HlFuM5/6p+2gTwA53dAy4jzY1RgMr2mN 1iSwHN2zU+dVYxUAw7GMu4HmDAnUuDN7NvtMGh6lynJwVhlVzI4hsRp63kN2874xpQbd BxhUfFRWq0N4iIaVXrNVZqizITMBzmF/ITN2t5z/Tdn0oM4v6ogSAUGr5bV1OosdPtmO e7IPxGObsYywbmgOyxqr60EAtTPTFjymZlkHk3J7bLgBtsBAeubxvXamh0G5Lh/CAsG4 Bswg== MIME-Version: 1.0 References: <20190819032918.3536-1-sergiodj@redhat.com> <87wof9nu65.fsf@redhat.com> In-Reply-To: <87wof9nu65.fsf@redhat.com> From: Ruslan Kabatsayev Date: Mon, 19 Aug 2019 14:57:00 -0000 Message-ID: Subject: Re: [PATCH] Improve ptrace-error detection on Linux targets To: Sergio Durigan Junior Cc: GDB Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00411.txt.bz2 On Mon, 19 Aug 2019 at 16:47, Sergio Durigan Junior w= rote: > > On Monday, August 19 2019, Ruslan Kabatsayev wrote: > > > Hello Sergio, > > Hey Ruslan, > > > On Mon, 19 Aug 2019 at 06:29, Sergio Durigan Junior wrote: > >> > >> In Fedora GDB, we carry the following patch: > >> > >> https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-attach-fail= -reasons-5of5.patch > >> > >> Its purpose is to try to detect a specific scenario where SELinux's > >> 'deny_ptrace' option is enabled, which prevents GDB from ptrace'ing in > >> order to debug the inferior (PTRACE_ATTACH and PTRACE_ME will fail > >> with EACCES in this case). > >> > >> I like the idea of improving error detection and providing more > >> information to the user (a simple "Permission denied" can be really > >> frustrating), but I don't fully agree with the way the patch was > >> implemented: it makes GDB link against libselinux only for the sake of > >> consulting the 'deny_ptrace' setting, and then prints a warning if > >> ptrace failed and this setting is on. > >> > >> Instead of printing a very certain warning about a very specific > >> setting, I decided to propose the following patch, which prints a > >> generic warning about a possible situation (i.e., without going > >> bothering to make sure that the situation is actually happening). > >> What this means is that whenever a ptrace error is detected, and if > >> errno is either EACCES or EPERM, a warning will be printed pointing > >> the user to our documentation, where she will find more details about > >> possible restrictions in place against ptrace. > > > > Doesn't it worsen user experience compared to the current Fedora > > patch? Now a user first coming across the problem will have to > > navigate the documentation, then check possible scenarios =E2=80=93 ins= tead of > > simply getting a friendly explanation what exactly is wrong. > > I agree that it is easier to just print the reason for the failure > directly, instead of pointing to the documentation. However, the reason > I chose the latter is because it may not always be possible to identify > the reason, and this might confuse the user or lead him to wrong > conclusions. I'm mostly thinking about the seccomp feature here > (because I have no idea how to check if it's active or not), but I'm > also concerned that it's unreasonable to expect users to have > libselinux-devel (on Fedora) installed. > > > Compare this with the patch applied by some Linux distributions > > (CentOS IIRC) to make Bash emit > > > >> bash: myprogram: /lib/ld-linux.so.2: bad ELF interpreter: No such file= or directory > > > > when ELF interpreter can't be found. By default, Bash only prints the > > less than helpful message > > > >> bash: myprogram: No such file or directory > > > > Your proposal (if it's intended to replace Fedora's GDB patch) is > > similar to replacing this default with > > > >> bash: myprogram: No such file or directory. There might be other reaso= ns than simply command executable not existing. Please see Bash documentati= on section XYZ for details. > > > > and adding a section XYZ in Bash docs explaining that the reasons > > could include lacking libraries, broken symlink to the binary, stale > > hash table of PATH lookups, etc.. This is considerably worse than the > > patch with explicit announcement of actual problem. > > Well, in this specific case it's probably not difficult to check for the > right cause and print the specific warning. However, if there were more > than 2 or 3 scenarios where a program couldn't be executed, and if > checking for them involved depending on external libraries and such, > then we'd be talking about a similar situation here. > > > So as a user, I disfavor this approach, although it might be more > > maintainable for GDB developers. But, if dependency on libselinux is > > the only objection, then why not simply dlopen it as needed (and > > gracefully handle failure to do so) instead of ELF-level linking to > > it? Then there'll be no hard dependency on libselinux, while user > > experience will not degrade too. > > Thanks for expressing your opinion as user, much appreciated! > > I had considered dlopen'ing libselinux before, but didn't do that > because of what I mentioned earlier: I think it's not reasonable to > expect that the user will have libselinux-devel installed, and SELinux > is just one of the possible scenarios here. > > But your message made me rethink and decide to do the following: > > - Try to dlopen libselinux, and check for deny_ptrace if possible. If > it works and deny_ptrace is on, emit a specific warning about it. If > it doesn't work or if deny_ptrace is off, continue. > > - Try to check the contents of /proc/sys/kernel/yama/ptrace_scope. If > it works and if ptrace_scope > 0, emit a specific warning about it. > Otherwise, continue. > > - See if I can come up with a way to check the seccomp thing. If > possible, emit a specific warning about it. Otherwise, continue. > > - If everything failed, emit a generic warning pointing to the docs. Yes, I did consider suggesting the same, just thought it would look too complicated to have both generic and specific cases. I'm glad that you've come to this solution anyway. > > I hope this is a better approach. > > Thanks, > > -- > Sergio > GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 > Please send encrypted e-mail if possible > http://sergiodj.net/ Thanks, Ruslan