From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WD1SIvE/XWi6LCAAWB0awg (envelope-from ) for ; Thu, 26 Jun 2025 08:41:21 -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=LcAyJiYA; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 881EB1E11E; Thu, 26 Jun 2025 08:41:21 -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 86C631E089 for ; Thu, 26 Jun 2025 08:41:20 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2CE5C385B52C for ; Thu, 26 Jun 2025 12:41:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2CE5C385B52C 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=LcAyJiYA 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 5956F385B511 for ; Thu, 26 Jun 2025 12:40:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5956F385B511 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 5956F385B511 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=1750941643; cv=none; b=vMlH7nxNeZ4X5Xwt34YafWaY+YYHVFxMWmLVRZRkIlKZqL0M8fyPej8xsMs67jovKcC91FpKeHZm7sbgYW+Vj0nFUw5lX5Rsn+EO8/WJArf2ljLg9hXAvmvV28ZGwpqNALu/og0aYQyk3O7CmTBId17iprpIteVxcuK60+4KDwU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1750941643; c=relaxed/simple; bh=Ge1GyH4ejE+sFVqIFMnSj5ToS0amKneobLHcm0H4Fvo=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ME/PObiq9Zgao9HW2/oG7SKPiIfRwSlWJiePUJ9hLDgHZhm32vIoR9+h9FcPmr6vsZJUlObi7YtyYt8mVKh2atCEXlmEb6E2JcWIzY5e6ZRj06jeNbJqoK9gLka+qQB6DIk1KNVvVHqELwy7ewbsLTeBHzv3iyqycEGHF8OP9b8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5956F385B511 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1750941643; 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=qPOhDmzaYF0be6azDtYzzcM6cdEz3u6VC8acDlOxtsc=; b=LcAyJiYAeb9abHmhYiBcA6WOaX/LvmnjMqq0MvG3dzUWJM9v2Kh+Si99CWYnCi0yAuEa3U v1IUVst9KP2/P1eI0botlMocml3akge2HnsNlz0CAu25FeHOwJMazEbZ6UtgK3guYKQSTb m8PX9W03L5aSy+5a9/NXKBe93AyLMuc= 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-614-esW-82qZP_eg3Cy2MzaNiA-1; Thu, 26 Jun 2025 08:40:41 -0400 X-MC-Unique: esW-82qZP_eg3Cy2MzaNiA-1 X-Mimecast-MFC-AGG-ID: esW-82qZP_eg3Cy2MzaNiA_1750941640 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-451d3f03b74so5157165e9.3 for ; Thu, 26 Jun 2025 05:40:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750941640; x=1751546440; 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=qPOhDmzaYF0be6azDtYzzcM6cdEz3u6VC8acDlOxtsc=; b=U9SyKBtZwIlz1lQc/1g5vLRhsQYFtMHjjdSMxNzGSaPIwzWRX/siQYyQRu3i6y294P covXrfPFXKAX0zazaifnzDTlBwfQQmW7iX+Bnl9ID4CB6IkYyTfP1rCkjXtZqi850xWA k6VgEVs7n2bQAHAk4CpPf8HO330xr0/ZBEht0LlcRWBefOrJ0kk4c6duo2pXg9NU4EBs gzEeqnMPRFcv8MqgoXFxjDAC804x4s8H5V6QEuTnxz4+Gvz3p1yrWZIGiwGnwn9W+HLM SYc1yvItEHGdqXMTMo5iVJXLx/miTGt6ttSkuwOvMa2Ung+kofSPayjrzJulkZh6xL+i Zm9g== X-Forwarded-Encrypted: i=1; AJvYcCXe1KcJRmlS+2xYWPJO1nZlNu9bpze8BhzqC6gU+WYrChDCLfxGn/0saqHDjJOIV+Yt33F5QRrG+/+ppA==@sourceware.org X-Gm-Message-State: AOJu0Yw/o1DUB67zjpHdmMFbxCVMe4khXvFmKsIKbXq8j7JayerOVazi i2QcKNzBBdyANBke2hXcVwWj/I+to8lyztP+/kI5F9vzxdYkWjKX5FMQhJPATekYT6aY4pCp6ZQ ss5ie2FylkaPIqWRj0+wKXiK61q8VpV0ES2p+JM3FKaCV9Ud8YTLrw5nOZCes+tLtmkIMLL8= X-Gm-Gg: ASbGncv3OjYz0rdfPc9XbdhpsYtWAYA20VFRrgg7jrJ1AQB8ZIBKudlk2I0fnh3JSi+ toYRtdUXhdID6XN9CEKJwr6dZL736zaLtQ4yJBc9PX8TX/AONa2nHzlADd+5JRhxP4qG67ptQqI L6rN6fMWHOrF2YJv3Zryb6StcTl/6OTGxh4G222zU28+RTo6YWDvo4QnU3vw+oq6UoV27+G8NTo H88nRrZEIZrctAtmKv4hqhQ0JFU0XInBNSmkJbGzF3y2bfZNcwsEwtk/d0XlKjRulFvT9XQHQZ9 5yBGpYmrJWSdBAzzSKZFqzJYLnm5s8R4L8kH85gxCRgaHNw= X-Received: by 2002:a05:600c:3b03:b0:442:ffa6:d07e with SMTP id 5b1f17b1804b1-45381aa4abbmr64132535e9.1.1750941639941; Thu, 26 Jun 2025 05:40:39 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHwUwRf8mwQSadJzkMhAErGngf8YQ8Ao2jxDRqfkOij8IunT+FMpdlQfzVOi2RNdPfwsvWKPw== X-Received: by 2002:a05:600c:3b03:b0:442:ffa6:d07e with SMTP id 5b1f17b1804b1-45381aa4abbmr64132195e9.1.1750941639430; Thu, 26 Jun 2025 05:40:39 -0700 (PDT) Received: from localhost (75.226.159.143.dyn.plus.net. [143.159.226.75]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4538a390d55sm19495865e9.6.2025.06.26.05.40.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Jun 2025 05:40:38 -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: References: <824ee908821f07452286730643c1efd5f8b01eb2.1749741769.git.aburgess@redhat.com> <87qzzak1ct.fsf@redhat.com> <68c9f369-bd11-48dd-90c8-8c7a61771de7@suse.de> <87ecv8jejc.fsf@redhat.com> <9656c79d-fb13-4689-9254-d59262d9ca6c@suse.de> <878qlfkivv.fsf@redhat.com> Date: Thu, 26 Jun 2025 13:40:37 +0100 Message-ID: <875xgik75m.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 4cFkzKGvhNiX56woGNxqDltjhbeOxsaVl_tN35-rrfE_1750941640 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/25/25 16:15, Andrew Burgess wrote: >> Tom de Vries writes: >> >>> On 6/25/25 12:34, Andrew Burgess wrote: >>>> 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. >>>> >>> >>> Hi Andrew, >>> >>> thanks for picking this up. >>> >>> FWIW, the problem with this solution is that a timeout now looks like >>> unsupported. >>> >>> More concretely, by doing this (on x86_64-linux, where the test-case >>> passes for me): >>> ... >>> diff --git a/gdb/testsuite/gdb.base/user-namespace-attach.exp >>> b/gdb/testsuite/gdb.base/user >>> -namespace-attach.exp >>> index 01f3dae1693..c5ec5ef6369 100644 >>> --- a/gdb/testsuite/gdb.base/user-namespace-attach.exp >>> +++ b/gdb/testsuite/gdb.base/user-namespace-attach.exp >>> @@ -66,6 +66,7 @@ proc run_test { flags } { >>> } >>> >>> set inferior_pid [spawn_id_get_pid $inferior_spawn_id] >>> + sleep 90 >>> >>> clean_restart >>> >>> ... >>> I trigger the timeout of 60 seconds in the exec, and with your patch get: >>> ... >>> === gdb Summary === >>> >>> # of unsupported tests 3 >>> ... >>> but without your patch I get: >>> ... >>> # of unexpected failures 6 >>> ... >>> >>> I don't think it's terribly important though. >>> >>> You could try the approach I proposed in the PR, or you could pursue >>> this one. >>> >>> In the latter case, please add a comment that a timeout may trigger the >>> same message. >> >> You make a good point. I think your suggestion is probably the best >> approach then. How about the patch below? >> > > LGTM. > > I've also tested it on x86_64-linux, where the test-case still passes, > and on arm-linux, where the test-case now results in 3 times unsupported. > I pushed this patch. Thanks, Andrew