From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81030 invoked by alias); 5 Sep 2019 12:19:34 -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 81021 invoked by uid 89); 5 Sep 2019 12:19:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=surely 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 ESMTP; Thu, 05 Sep 2019 12:19:32 +0000 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A24F481DFF for ; Thu, 5 Sep 2019 12:19:29 +0000 (UTC) Received: by mail-wr1-f70.google.com with SMTP id o11so902884wrq.22 for ; Thu, 05 Sep 2019 05:19:29 -0700 (PDT) Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id j1sm2782043wrg.24.2019.09.05.05.19.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Sep 2019 05:19:27 -0700 (PDT) Subject: Re: [PATCH v2] Improve ptrace-error detection on Linux targets To: Sergio Durigan Junior References: <20190819032918.3536-1-sergiodj@redhat.com> <20190826183205.19008-1-sergiodj@redhat.com> <28c4f743-91f1-59c3-83ff-3f791811f996@redhat.com> <87mufrai1z.fsf@redhat.com> <87zhjjrh7n.fsf@redhat.com> <87d0gfrewj.fsf@redhat.com> <587b2e6b-15ec-0ba1-f425-82ec45eb4ca7@redhat.com> <875zm7rd9v.fsf@redhat.com> <8b3979cd-8c24-42e0-334b-de02cda2b799@redhat.com> <871rwvrbf5.fsf@redhat.com> Cc: GDB Patches , Eli Zaretskii , Ruslan Kabatsayev From: Pedro Alves Message-ID: <491150f7-636f-4629-ac68-2a4597bd703d@redhat.com> Date: Thu, 05 Sep 2019 12:19:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <871rwvrbf5.fsf@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-09/txt/msg00052.txt.bz2 On 9/4/19 10:36 PM, Sergio Durigan Junior wrote: > On Wednesday, September 04 2019, Pedro Alves wrote: > >> On 9/4/19 9:56 PM, Sergio Durigan Junior wrote: >>>> You could start gdbserver with the restrictions off (like a long >>>> lived daemon), and then while gdbserver is running enable >>>> restrictions, I suppose. >>> Ah, right, I think that would also work. >> >> I'm interested in knowing whether the error percolates to >> the gdb side in a reasonable form. > > The attach error is displayed by GDB, but the information about ptrace > restrictions is not. > > This is what I see on GDB: > > (gdb) attach 32378 > Attaching to process 32378 > Attaching to process 32378 failed > > And this is what I see on gdbserver: > > gdbserver: Cannot attach to process 32378: Permission denied (13), the SELinux boolean 'deny_ptrace' is enabled, you can disable this process attach protection by: (gdb) shell sudo setsebool deny_ptrace=0 > > > I think there's something wrong with the terminal settings because > newlines aren't being respected here. But the message is still there, > and the user can still understand it, I think. Odd. We should fix that... But this made me realize something. Here: static int linux_child_function (void *child_stack) { - ptrace (PTRACE_TRACEME, 0, (PTRACE_TYPE_ARG3) 0, (PTRACE_TYPE_ARG4) 0); + if (ptrace (PTRACE_TRACEME, 0, (PTRACE_TYPE_ARG3) 0, + (PTRACE_TYPE_ARG4) 0) != 0) + trace_start_error_with_name ("ptrace", + linux_ptrace_me_fail_reason (errno).c_str ()); + This is code that is run by the fork child. Recall that we had introduced trace_start_error_with_name instead of using perror_with_name / error, because between after fork and before exec, we can only safely use async-signal-safe functions. But that linux_ptrace_me_fail_reason call is doing a lot of non-async-signal safe things... I think the right approach would be to make the child pass back the errno value to the parent, and then have the parent, do the dlopens, the std::string/malloc uses, etc. and print the error messages. The traditional way to pass data around like this is via a pipe. darwin-nat.c uses a pipe around fork, see ptrace_fds, though for a different reason. > Ideally we'd have GDB also display the ptrace restriction warning, but I > think that if the user can see that the attach failed, she will likely > look at what happened with gdbserver, and will see the error there. I don't think that assuming that the user has easy/convenient access to gdbserver's terminal is a great assumption. Consider IDEs automating things, or gdbserver really being used as a service in a container, etc. Note that at least for Yama, you can have ptrace allow PTRACE_ME, while PTRACE_ATTACH gets refused. So it's not guaranteed that gdbserver would exit out early on start up, meaning, I think that handling this gdbserver + "(gdb) attach" error case isn't being pedantic. > If > we were to show the message on GDB, we'd also have to rewrite it in a > way that explains that the command needs to be run at the target, which > may confuse things. Or it may not confuse things? I don't think that should prevent improving things. Surely we can find some way to express the message without causing confusion. I'm not sure it does, but if it does, maybe we can just append a "on the target system" somewhere? Thanks, Pedro Alves