From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75232 invoked by alias); 24 Sep 2019 20:40:48 -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 75223 invoked by uid 89); 24 Sep 2019 20:40:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=measures, junior, randomly X-HELO: gateway21.websitewelcome.com Received: from gateway21.websitewelcome.com (HELO gateway21.websitewelcome.com) (192.185.46.113) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Sep 2019 20:40:45 +0000 Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway21.websitewelcome.com (Postfix) with ESMTP id 70DBB400EFE51 for ; Tue, 24 Sep 2019 15:40:44 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id Crc4iB3cj2PzOCrc4i1LZ7; Tue, 24 Sep 2019 15:40:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GObD89Veb7X6T9GF/f9z4hPpoEHc6c+8UFjD5ewrDKI=; b=XgKHTxTZIVPqhZ79BmcRacmF0M cuU6ynglocXBu3rSV1ea7I7LLIRqNhV4rsk8cxirZfFnogeNwLE2WwUVxIonhhS2VEyyZxcg7Jucf G2J9Nm/fH91+0vNih8JDdVTs0; Received: from 71-218-73-27.hlrn.qwest.net ([71.218.73.27]:40696 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iCrc3-001adQ-Tr; Tue, 24 Sep 2019 15:40:44 -0500 From: Tom Tromey To: Sergio Durigan Junior Cc: GDB Patches , Pedro Alves , Eli Zaretskii , Ruslan Kabatsayev Subject: Re: [PATCH v4] Improve ptrace-error detection on Linux targets References: <20190819032918.3536-1-sergiodj@redhat.com> <20190911011103.12774-1-sergiodj@redhat.com> Date: Tue, 24 Sep 2019 20:40:00 -0000 In-Reply-To: <20190911011103.12774-1-sergiodj@redhat.com> (Sergio Durigan Junior's message of "Tue, 10 Sep 2019 21:11:03 -0400") Message-ID: <87h851mnqt.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-09/txt/msg00470.txt.bz2 >>>>> "Sergio" == Sergio Durigan Junior writes: Sergio> Changes from v3: Thanks for doing this. I like this change quite a bit. For one thing I think it would have saved me some time over the years, as I randomly forget about ptrace security measures on new machines. Sergio> +++ b/gdb/gdbserver/server.c Sergio> @@ -2913,9 +2913,21 @@ handle_v_attach (char *own_buf) Sergio> { Sergio> client_state &cs = get_client_state (); Sergio> int pid; Sergio> + int ret; Sergio> pid = strtol (own_buf + 8, NULL, 16); Sergio> - if (pid != 0 && attach_inferior (pid) == 0) Sergio> + Sergio> + try Sergio> + { Sergio> + ret = attach_inferior (pid); Sergio> + } Sergio> + catch (const gdb_exception_error &e) Sergio> + { Sergio> + sprintf (own_buf, "E.%s", e.what ()); Unrestricted sprintf gives me pause. Do we know own_buf is large enough? Or can/should we truncate the text instead? Sergio> -gdb_dlopen (const char *filename) Sergio> +gdb_dlopen (const char *filename, bool dont_throw) This parameter is only used in one spot, and it's on an error path that is computing the string to show to the user. So, I think it's better to just remove the parameter and use try/catch in that one caller. Sergio> +static std::string Sergio> +linux_ptrace_restricted_fail_reason (int err) Sergio> +{ ... Sergio> + std::string ret; Sergio> + gdb_dlhandle_up handle = gdb_dlopen ("libselinux.so.1", true); Sergio> + Sergio> + if (handle != nullptr) Sergio> + { Sergio> + selinux_ftype selinux_get_bool Sergio> + = (selinux_ftype) gdb_dlsym (handle, "security_get_boolean_active"); Sergio> + Sergio> + if (selinux_get_bool != NULL Sergio> + && (*selinux_get_bool) ("deny_ptrace") == 1) Sergio> + string_appendf (ret, Sergio> + _("\n\ Sergio> +The SELinux 'deny_ptrace' option is enabled and preventing GDB\n\ Sergio> +from using 'ptrace'. You can disable it by executing (as root):\n\ Sergio> +\n\ Sergio> + setsebool deny_ptrace off\n")); Sergio> + } Sergio> + Sergio> + gdb_file_up yama_ptrace_scope Sergio> + = gdb_fopen_cloexec ("/proc/sys/kernel/yama/ptrace_scope", "r"); ... If SELinux was the problem, is it also possible that ptrace_scope is the problem? I was wondering if each case should just return, or if checking each one is the correct thing to do here. thanks, Tom