From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WKzGD9DQW2iNxh0AWB0awg (envelope-from ) for ; Wed, 25 Jun 2025 06:34:56 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=CXrgpnix; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 3080D1E11C; Wed, 25 Jun 2025 06:34:56 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-10.1 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 444561E089 for ; Wed, 25 Jun 2025 06:34:55 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BC79E3857BBA for ; Wed, 25 Jun 2025 10:34:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BC79E3857BBA Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=CXrgpnix Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 4062F3857C67 for ; Wed, 25 Jun 2025 10:34:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4062F3857C67 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4062F3857C67 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1750847660; cv=none; b=l++L/XPAQJRXWI8zrGhi29Mpg7G1fkPTLGtpuD9TlOBOHgyJbQJFDQtQZ4NiE49FfXzBxJhTESy3jztEcaIoyxaOxfelCx3ZrEMmw9Jog1aJ7MF3NETQiQ0v3PZrLW/GOLJFr6a6gCNl0cqu4V1HDTT56oHEfLHIpQYRTEq6HAs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1750847660; c=relaxed/simple; bh=eLPRzkOsP9UE/ar7yi/FuY8am82zoW9SzQcxlHsCFCg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=BidtYB8FJhygad/x4sYsab6qyfPOdDqd/3gw7uM6Ur7QrwMEjS8O/dCwHA/SPSFOEHp2wwgQybczwH0pfePwyr57QkoBEhIALEA5cg8I8ByKxZeSGLiMtuyQA9t3OrtNOIsgEzB4BFR9xZrR4OgfcIc9TpskcUFt0ylbnCz5M08= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4062F3857C67 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1750847660; 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=9TxJKohun8HhIV1rBuw53N+wMdDdOmw00iC69rKBTfU=; b=CXrgpnixn8LH58s4KGluVlvDI1oiDOeEni0C7I8Li45zrrPvPwfO057Jf9cjvRkjuhMjeH is39NB7G8+045VY8jONizuIsdLvUEWfOPvsaSRt1+e3xeglNHBLYvFEEHQ05qvNGjwWVPs NzHQDc0ICBKjvTe/Syirpkn3sILztqE= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-62-X5DrNu-0Piqnjk70GHFnow-1; Wed, 25 Jun 2025 06:34:18 -0400 X-MC-Unique: X5DrNu-0Piqnjk70GHFnow-1 X-Mimecast-MFC-AGG-ID: X5DrNu-0Piqnjk70GHFnow_1750847657 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-453817323afso5019195e9.1 for ; Wed, 25 Jun 2025 03:34:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750847657; x=1751452457; 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=9TxJKohun8HhIV1rBuw53N+wMdDdOmw00iC69rKBTfU=; b=Uv4SiWUyDXkyXY2NhQIOAPjpd+Kdu7ywHiI6cbZ0XsFO4ItGwVKYd+zJ7wuUV/MXR7 fCpQQqZ0FCT00AZB9B0LnFfPWTmzu7ZapE5m1x9ykh1hbPbP2FWTddNj8sDHI16JFrvU wi+/Q+OQkSS7mqIKZhkNGYBLe/wCAaK7DEaNO5CBUgx86Hk0DTvgKpWTxVS5vI9eeGdR CApAbOIVqVlypVzS9SXZAAW97ho6bhsWCxjyLOdBGPhxcs60C4hb9H0j2MFD3zuwVjpO jGAST6X5H5bxpBKmVl7MFRhfO1QYaJXvZ/ixGS40x89AI97h4utaomSxmgVMZw2YjOwB X/9Q== X-Forwarded-Encrypted: i=1; AJvYcCWroDHoFYhurrmO1omXNNznH6VsmDi8horsvZZwgBGImfrF0Pv3LAlpII+1DgIKKECoqu8k9ytmL8w3jg==@sourceware.org X-Gm-Message-State: AOJu0YxuQekPwi/wt9I+G3toeJVY2az9dQ4j0g0vOTeH0ttl0lwC143E r+a32311m2VG1DQT0i/ypyrqRYVpP2hGbDouT2Q0ebMkh4J5tG/s3ByfgpLhhquQF3zB1plPXtL /zZng3NTPsZbdx/3C4WPcpbos1/mzTNwCv0mYTKcx1DtzoI/KvrcWYQnvirCXJ6s= X-Gm-Gg: ASbGncv+HlF0pxHPCkpprhCsDul5pxZWRgSg3gvmBr+64oRGgvw3wV8aYLqGhOHFHk5 PheMzbjpcMWC9GyTa0sFr013GgYe2sc6g1gqPpf2dbofsALhMQ/nMFic+AXNST0NoSkjSkuiZ5L mBU7tbsh0sjmeV+1HEM6wE5PuVzlE01+sVm2kcQaRYCrvcYQZqn3pg+xPixx3CONV0Kjr5yhlnl TP4BU3T3yU1ifaaUnEdXJq0zPLRTVN57u/EbHxp6U3qfWV0+qZkpGtn1ZLlvFaMeRFgZwDCe+8H 6xUF9IJbBnBwlGFL1m88c2dlIkaLbBh+cwFGhgM9NOcqMYs= X-Received: by 2002:a05:600c:358f:b0:450:d37d:7c with SMTP id 5b1f17b1804b1-4538685c6a5mr1049785e9.21.1750847657161; Wed, 25 Jun 2025 03:34:17 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH2Ggogkz7DY6Ei4FMfUdmbVADiAOZHiIvasscdP7b3Nv1xZrW+NvQR/9rzs7hH4kxm/HvNiQ== X-Received: by 2002:a05:600c:358f:b0:450:d37d:7c with SMTP id 5b1f17b1804b1-4538685c6a5mr1049365e9.21.1750847656602; Wed, 25 Jun 2025 03:34:16 -0700 (PDT) Received: from localhost (75.226.159.143.dyn.plus.net. [143.159.226.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a6e805e828sm4332903f8f.32.2025.06.25.03.34.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Jun 2025 03:34:16 -0700 (PDT) From: Andrew Burgess To: Tom de Vries , gdb-patches@sourceware.org Cc: Benjamin Berg Subject: Re: [PATCHv3] gdb: linux-namespaces: enter user namespace when appropriate In-Reply-To: <68c9f369-bd11-48dd-90c8-8c7a61771de7@suse.de> References: <824ee908821f07452286730643c1efd5f8b01eb2.1749741769.git.aburgess@redhat.com> <87qzzak1ct.fsf@redhat.com> <68c9f369-bd11-48dd-90c8-8c7a61771de7@suse.de> Date: Wed, 25 Jun 2025 11:34:15 +0100 Message-ID: <87ecv8jejc.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: LELGZJ-Iqcbis138Dxq4IsPuFumlbVPqIpUerN5woac_1750847657 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Tom de Vries writes: > On 6/23/25 15:56, Andrew Burgess wrote: >> Andrew Burgess writes: >> >>> From: Benjamin Berg >>> >>> In v2: >>> >>> - Update the test to ignore a warning seen when running the test on >>> a machine with libc debug information installed, but without the >>> libc source being available, e.g.: >>> >>> warning: 46 ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory >>> >>> This was causing some CI failures to be reported from Linaro. >>> >>> - Rebased to current upstream/master. >>> >>> In v3: >>> >>> - Same as V2, but fix the test pattern correctly this time. >>> >>> -- >>> >>> The use of user namespaces is required for normal users to use mount >>> namespaces. Consider trying this as an unprivileged user: >>> >>> $ unshare --mount /bin/true >>> unshare: unshare failed: Operation not permitted >>> >>> The problem here is that an unprivileged user doesn't have the >>> required permissions to create a new mount namespace. If, instead, we >>> do this: >>> >>> $ unshare --mount --map-root-user /bin/true >>> >>> then this will succeed. The new option causes unshare to create a >>> user namespace in which the unprivileged user is mapped to UID/GID 0, >>> and so gains all privileges (inside the namespace), the user is then >>> able to create the mount namespace as required. >>> >>> So, how does this relate to GDB? >>> >>> When a user attaches to a process running in a separate mount >>> namespace, GDB makes use of a separate helper process (see >>> linux_mntns_get_helper in nat/linux-namespaces.c), which will then use >>> the `setns` function to enter (or try to enter) the mount namespace of >>> the process GDB is attaching too. The helper process will then handle >>> file I/O requests received from GDB, and return the results back to >>> GDB, this allows GDB to access files within the mount namespace. >>> >>> The problem here is that, switching to a mount namespace requires that >>> a process hold CAP_SYS_CHROOT and CAP_SYS_ADMIN capabilities within >>> its user namespace (actually it's a little more complex, see 'man 2 >>> setns'). Assuming GDB is running as an unprivileged user, then GDB >>> will not have the required permissions. >>> >>> However, if GDB enters the user namespace that the `unshare` process >>> created, then the current user will be mapped to UID/GID 0, and will >>> have the required permissions. >>> >>> And so, this patch extends linux_mntns_access_fs (in >>> nat/linux-namespace.c) to first try and switch to the user namespace >>> of the inferior before trying to switch to the mount namespace. If >>> the inferior does have a user namespace, and does have elevated >>> privileges within that namespace, then this first switch by GDB will >>> mean that the second step, into the mount namespace, will succeed. >>> >>> If there is no user namespace, or the inferior doesn't have elevated >>> privileges within the user namespace, then the switch into the mount >>> namespace will fail, just as it currently does, and the user will need >>> to give elevated privileges to GDB via some other mechanism (e.g. run >>> as root). >>> >>> This work was originally posted here: >>> >>> https://inbox.sourceware.org/gdb-patches/20230321120126.1418012-1-benjamin@sipsolutions.net >>> >>> I (Andrew Burgess) have made some cleanups to the code to comply with >>> GDB's coding standard, and the test is entirely mine. This commit >>> message is also entirely mine -- the original message was very terse >>> and required the reader to understand how the various namespaces >>> work and interact. The above is my attempt to document what I now >>> understand about the problem being fixed. >>> >>> I've left the original author in place as the core of the GDB change >>> itself is largely as originally presented, but any inaccuracies in the >>> commit message, or problems with the test, are all mine. >>> >>> Co-Authored-by: Andrew Burgess >> >> I've pushed this patch. >> > > The new test-case fails on arm32 (Linaro CI reported this, and I was > able to reproduce) due to insufficient permissions: > ... > (gdb) attach 184732 > Attaching to process 184732 > warning: process 184732 is a zombie - the process has already terminated > ptrace: Operation not permitted. > (gdb) FAIL: gdb.base/user-namespace-attach.exp: flags=--mount > --map-root-user: attach to inferior > ... > > In essence, the test-case assumes: > ... > $ unshare --mount --map-root-user /bin/true; echo $? > 0 > ... > but we get instead: > ... > $ unshare --mount --map-root-user /bin/true; echo $? > unshare: unshare failed: Operation not permitted > 1 > ... > > Filed here ( https://sourceware.org/bugzilla/show_bug.cgi?id=33108 ). Hi! Thanks for raising this issue. What do you think to the patch below? I've tested this by passing a bogus flag to `unshare`, e.g. "unshare -blahblah", which has the same effect of causing the `unshare` process to exit immediately with an exit code of 1. I now see the test reported as unsupported. Thanks, Andrew --- commit 1c61ee90c22666a6f33a474c27a901d03bbc5da9 Author: Andrew Burgess Date: Wed Jun 25 11:24:30 2025 +0100 gdb/testsuite: handle failure to start process to later attach to Commit: commit b23903836007d1acaf7f8c059ab000ee83fcebfa Date: Tue Mar 21 13:01:26 2023 +0100 gdb: linux-namespaces: enter user namespace when appropriate added a new test gdb.base/user-namespace-attach.exp. It has been reported that this test will sometimes fail, like this: (gdb) attach 184732 Attaching to process 184732 warning: process 184732 is a zombie - the process has already terminated ptrace: Operation not permitted. (gdb) FAIL: gdb.base/user-namespace-attach.exp: flags=--mount --map-root-user: attach to inferior the test tries to run the 'unshare' application. Sometimes though, the application is present, but the set of flags used is not supported (maybe due to restrictions on the local machine), so we see behaviour like this: $ unshare --mount --map-root-user /bin/true; echo $? unshare: unshare failed: Operation not permitted 1 Handle this case by checking for the warning: warning: process 184732 is a zombie - the process has already terminated when GDB tries to attach. If we see this warning then we assume the 'unshare' process failed to start correctly, in which case we report the test as unsupported and perform an early return. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33108 diff --git a/gdb/testsuite/gdb.base/user-namespace-attach.exp b/gdb/testsuite/gdb.base/user-namespace-attach.exp index 9936bb998eb..01f3dae1693 100644 --- a/gdb/testsuite/gdb.base/user-namespace-attach.exp +++ b/gdb/testsuite/gdb.base/user-namespace-attach.exp @@ -69,12 +69,18 @@ proc run_test { flags } { clean_restart + set saw_failure_to_start false set saw_bad_warning false gdb_test_multiple "attach $inferior_pid" "attach to inferior" { -re "^attach $::decimal\r\n" { exp_continue } + -re "^warning: process $::decimal is a zombie - the process has already terminated\r\n" { + set saw_failure_to_start true + exp_continue + } + -re "^warning: \[^\r\n\]+: could not open as an executable file: \[^\r\n\]+\r\n" { set saw_bad_warning true exp_continue @@ -112,6 +118,11 @@ proc run_test { flags } { } -re "^$::gdb_prompt $" { + if { $saw_failure_to_start } { + unsupported "unshare process failed to start" + return + } + gdb_assert { !$saw_bad_warning } $gdb_test_name }