From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1D6273858D20 for ; Wed, 20 Sep 2023 08:48:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1D6273858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695199708; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4+jfaRp7Zs+23fDTSn3v5SzTotDsySQSA6pgQ+MD9tY=; b=bo9wt73NWfeiDlwqAMviTsrde1ieAtDd8EPMYKhhiAEgc/H2FdyJ77Bcci2Or79YTu1RlM B44apgac36J58ysaxXec8JQkz8DJ6ZO+2S53kdTAtgu5wCxW3D22Yv4BS5qF00RkhUKiSb k6ycuw/krwvV+taIs26/4M1fmnnk1b0= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-448-aUZ5OYiVMf2Z7Te3RIXq8Q-1; Wed, 20 Sep 2023 04:48:27 -0400 X-MC-Unique: aUZ5OYiVMf2Z7Te3RIXq8Q-1 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-94a35b0d4ceso473028066b.3 for ; Wed, 20 Sep 2023 01:48:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695199706; x=1695804506; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4+jfaRp7Zs+23fDTSn3v5SzTotDsySQSA6pgQ+MD9tY=; b=j9skl3MZF15MM69h41AyMq/DcMupNWrIB1BbqoOgYEAGmk5lFB6vodq1GDmSzbCTEH aGU7HMSWiNiOJYlvkaUuiTa27Ck1yw8kWTGYC86MQnDrI1pZFMhoOjUebxnosqLixMOD PL6ymzJoO4WgklfFn7Fjen1gbYwy8Wga5c7MRQgLIAkWRcSwFD+28AAAEidEzJchMokt eFm2Yz8P2fUThqRIW8jhHA04PFx1ylIh2fS7i/f8FAGIGDU7oL/2yVBICqjntObTHJXG fOVfaPtvr88UUoWprC4NmgGGmvMaTIYMJWKlLSOOG3FyaUBLo2K5YhMNV9ZwaSXMpeH0 YDLA== X-Gm-Message-State: AOJu0YzzU6GSAcnIG05brCozZB33YgGXlgc8g+N5rUwUqoo+uHzZXjNL gPziEETo73IbHmnXduiaxBIQUwBQ3hvVj8uCsLdcWjLxEh8G6LQZN+gkS0k3hOUOJl6ZA7RzOAx ZBd61BEYRwfLCpLFyo8fLrfI2G2qWAbtfDhdkKot1PoeJVG8ZrVhs/KIW9s0JTpgbwsnC/N/SAg mw+fO5Og== X-Received: by 2002:a17:907:75c2:b0:9a1:d29c:6aa9 with SMTP id jl2-20020a17090775c200b009a1d29c6aa9mr1425321ejc.11.1695199705875; Wed, 20 Sep 2023 01:48:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFfHGgZgoz0RIZ86Ghx0FoL25Q99Nrtb49buFsXMNQZJpr2l29ACS4fd18mXNxnnUMyYnP1uA== X-Received: by 2002:a17:907:75c2:b0:9a1:d29c:6aa9 with SMTP id jl2-20020a17090775c200b009a1d29c6aa9mr1425307ejc.11.1695199705445; Wed, 20 Sep 2023 01:48:25 -0700 (PDT) Received: from localhost ([31.111.84.209]) by smtp.gmail.com with ESMTPSA id l21-20020a1709061c5500b009ad89697c86sm9150489ejg.144.2023.09.20.01.48.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 01:48:25 -0700 (PDT) From: Andrew Burgess To: Tyson Whitehead via Gdb-patches , gdb-patches@sourceware.org Cc: Tyson Whitehead Subject: Re: [PATCH] Fallback to direct access if lacking pemission for linux namespaces In-Reply-To: <20230919235134.2243437-1-twhitehead@gmail.com> References: <20230919235134.2243437-1-twhitehead@gmail.com> Date: Wed, 20 Sep 2023 09:48:24 +0100 Message-ID: <87zg1hxmav.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Tyson Whitehead via Gdb-patches writes: > The case where gdb and the target had the same path always used to > work. Now it fails if gdb and the target are in different namespaces > and gdb doesn't have permission to enter the target namespace. So I just read the bug report, and I think you did a better job there of explaining the background of why you wrote this patch. You should include the history in the commit message, instead of just saying that something used to work and now fails. > This commit causes gdb to fall back to trying direct access should > it lack permission to enter the namespace. This way it does not > break a case that used to work or require capabilites not required. Out of interest, did you consider doing: (gdb) set sysroot as a mechanism to solve your problem? This feels like a better solution to me, as this better describes your local setup. The problem I see with your proposal is that in the case where the namespace path _isn't_ visible to GDB, and if for some reason GDB isn't able to setns(), then the errors the user sees will be for GDB trying to open the namepsace path as if it were local -- which might give the impression that GDB is doing the wrong thing. If we are going to fall back to attempting local access (as a last ditched effort), then we should, at the very least, emit a warning to let the user know that we couldn't setns() and that we're trying local access as a last resort. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30113 > --- > gdb/nat/linux-namespaces.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/gdb/nat/linux-namespaces.c b/gdb/nat/linux-namespaces.c > index 4b1fee18425..8922717be10 100644 > --- a/gdb/nat/linux-namespaces.c > +++ b/gdb/nat/linux-namespaces.c > @@ -935,6 +935,13 @@ linux_mntns_access_fs (pid_t pid) > if (error == ENOSYS) > error = ENOTSUP; > > + /* EPERM indicates the required capabilites are not available > + for this. Fall back to the old direct gdb behaviour in > + order to not break cases where this used to work as the > + path could still be the same in both namespaces. */ The reference to "old direct gdb behaviour" here should be removed. It's OK to have comments like "This code exists for backwards compatibility with old GDB behaviour...", but that isn't the case here. The comment should justify the new code in terms of the desired behaviour of GDB, so something like: /* EPERM indicates the required capabilites to setns() are not available. It is possible that the file is directly visible to GDB, so, rather than just failing at this point, lets at least try direct access. */ if (error == EPERM) { warning (_("blah blah something about trying direct access")); return MNSH_FS_DIRECT; } Though I would recommend trying 'set sysroot' and seeing if that solves the access problems you are seeing. Thanks, Andrew > + if (error == EPERM) > + return MNSH_FS_DIRECT; > + > errno = error; > return MNSH_FS_ERROR; > } > -- > 2.40.1