From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aEq8GK4GXGhVmB4AWB0awg (envelope-from ) for ; Wed, 25 Jun 2025 10:24:46 -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=EdE8qMPB; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 610021E11E; Wed, 25 Jun 2025 10:24:46 -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 6DC3C1E0C2 for ; Wed, 25 Jun 2025 10:24:45 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1F2D33857007 for ; Wed, 25 Jun 2025 14:24:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1F2D33857007 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=EdE8qMPB 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 174FE385772A for ; Wed, 25 Jun 2025 14:15:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 174FE385772A 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 174FE385772A 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=1750860905; cv=none; b=lhFqQkqPO4V7sNEiZGWFyVP3tZ8WHifRVDRmFAeVwMNhPCYvfgmFXmafKT8x93qYeu7vpODWd4799kOv2Qpt/iJrp+f6CvLES2endKkU2h0571l0Uo9z1ZcApQ5pVtxrZn3wCmIElKbMfK8zljF0Lgv8ismjNWqrCWITHChRW54= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1750860905; c=relaxed/simple; bh=i73ilMJtQrSLlOnSt20SwDsFPmnmwu7ruhu528CPPDA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=m82UKhEPQRjZRKvdvK1a64IknAkHYcQDPnD8BUlpi/mBqKhWET01VG/KSRVpagMKCbOytb3Q8ztnz6cvxuksAJFiQ+FQMiR/YuT+5tEZfgv5gbK++I/uZg32W1a/jphW6cbwMAwbThijgVMCQwm0F8CJwBrZ2isLZs6SeWGInCw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 174FE385772A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1750860904; 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=FttRFmk3nQ632cp3fQ919ZBvkw4CFkC1HPC+GKZaGuM=; b=EdE8qMPBFrT0Jm3Si40G5F8bFFUr1pl3xTYQEWjc9fsbnR0mIROc4isXJ+6VDO4/2ls/mH IU+yk6HfDCrYTREnBd4sgpR0NAbOqXBMqNZ10rTbyVZxfHCR0x/80NX4mbnZ3HtfQegkt5 fptViXtV53KS3Ab8oH3sFDfkSMgYdG4= 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-468-r7U7RCK4ML2Tw4-nm5fBug-1; Wed, 25 Jun 2025 10:15:03 -0400 X-MC-Unique: r7U7RCK4ML2Tw4-nm5fBug-1 X-Mimecast-MFC-AGG-ID: r7U7RCK4ML2Tw4-nm5fBug_1750860902 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-451d3f03b74so10516125e9.3 for ; Wed, 25 Jun 2025 07:15:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750860902; x=1751465702; 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=FttRFmk3nQ632cp3fQ919ZBvkw4CFkC1HPC+GKZaGuM=; b=spj0OZmKA8dV4dtoHCjCV4TE9QNYmowgQgLekZ6oSGrdukIltuBf3xAGyUPIcWQtF7 o7OFu+xn3mZDw6eYagnso5VJfbJXKequdJVNnvgM/2GU3mtVwOSlRQ4SHQq3+/I/d5jz QTck4RXtwYRabT3/r67rIAGmesfEmoAApEaOtU77fPelPFgy2FaUChCs+ok+O+WF38Ek kDW4TE8+UekLgbBm662rou0jZiwS9aX+8i/FQ/wcwR0q7LcY6+Tmz38FWqRb/Rny33eU /Bp+i/QGx40zIrKYsXcPdgOz00RPhQyEoa8/EZAZphQXPcSI54wA+/Dk6+Dz4ikcSBIf oFiQ== X-Forwarded-Encrypted: i=1; AJvYcCV90mmOqZNr+7bg9p41IMZleTQZIXD2jYPtOqDwWIGpHLaWrsTi7MTt6GpKxhmpjjRI/XH/zHYi84l3/Q==@sourceware.org X-Gm-Message-State: AOJu0YwndjgOqOCjxGKumx9LCO3WflmrJrbkd3TZbmQPzyaTMwzhiqGg k4awgdkBNViyyx73Ryd9Gvi3I36Le6j4I1M+RgOiTzUgw3eZL/cYB5KhUmoYuS57fZ1jSjGEdJk iBQIdhZULpRGYTJ5GRX0yIObc52UUOm60nZw51jGEkD8V0z+aaCPzVJMgl0bLupM= X-Gm-Gg: ASbGncvqIleOocrM9fYbw4nQPzJzkvv1uTUrZKltiXJYITzbHY5+ohnRV+I8cs73U5q RccYk/1StpvBzghxkLy2GohmBPcFzyy1Baor4CXK+zzEiFgvp26lmVa21pZzrF9aDNKk5Zr/jCf seAFO2h0YU7E5gt8o/BlT7cvViPXjrnYFISh7gc6wPPMe8HnFkYM/XXJTJ2QIkCgIOfaN50/Tyr r5F+X0oLKXwmaS8ok3XkRJ2c+aqcVYfTPhG5+Q3O3M4oybTnvEHQBXpmVSgSdz3HoWYjtsaBcI7 AaoCzuf40o8dEq3Pjf2mguoj5WvXW6JIRaeUXGX6l2sQY7E= X-Received: by 2002:a05:6000:18a7:b0:3a4:eef5:dece with SMTP id ffacd0b85a97d-3a6ed65e7edmr3324284f8f.35.1750860901766; Wed, 25 Jun 2025 07:15:01 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFE5wmPaEVKmi1urx068MbyQQ0H8BVQyjyiPJS78IBv2iR2RAnV7rxBSouWYpxqluoNNZw9sQ== X-Received: by 2002:a05:6000:18a7:b0:3a4:eef5:dece with SMTP id ffacd0b85a97d-3a6ed65e7edmr3324246f8f.35.1750860901165; Wed, 25 Jun 2025 07:15:01 -0700 (PDT) Received: from localhost (75.226.159.143.dyn.plus.net. [143.159.226.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a6e8051f58sm4849001f8f.12.2025.06.25.07.15.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Jun 2025 07:15:00 -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: <9656c79d-fb13-4689-9254-d59262d9ca6c@suse.de> 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> Date: Wed, 25 Jun 2025 15:15:00 +0100 Message-ID: <878qlfkivv.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: BxRsOUuCnQbiRLdleiV9agSfEB-Hx-K1hcfkxr7hszo_1750860902 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 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? Thanks, Andrew --- 4d0265f72da gdb/testsuite: handle failure to start process for later attach test [Andrew Burgess (2 minutes ago)] diff --git a/gdb/testsuite/gdb.base/user-namespace-attach.exp b/gdb/testsuite/gdb.base/user-namespace-attach.exp index 9936bb998eb..741093c2c14 100644 --- a/gdb/testsuite/gdb.base/user-namespace-attach.exp +++ b/gdb/testsuite/gdb.base/user-namespace-attach.exp @@ -56,10 +56,22 @@ proc run_test { flags } { set prefix "" } + set unshare_cmd "unshare $flags" + # Run '/bin/true' using UNSHARE_CMD. If the flags in UNSHARE_CMD + # aren't supported then this will fail, this means we shouldn't + # spawn the command with our test executable and try attaching. + # + # This will also fail if /bin/true isn't present, or doesn't work + # as we expect. But this should be fine for many targets. + set res [remote_exec target "$unshare_cmd /bin/true"] + if { [lindex $res 0] != 0 } { + unsupported "unshare flags not supported" + return + } set inferior_spawn_id \ - [spawn_wait_for_attach [list "unshare $flags $::binfile"]] + [spawn_wait_for_attach [list "$unshare_cmd $::binfile"]] if { $inferior_spawn_id == -1 } { unsupported "failed to spawn for attach" return