From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 765F12741B5 for ; Sat, 29 Nov 2025 09:15:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764407713; cv=none; b=T+sFb63BoZbo+eSkDHO/ZL4Ir5ceZsxlHJ6srad3WyERdlxAfQ/kYekGje7Rn4z2BtFwa9Yo0R/XrKupZWep6P6cFewuiVmKadlApKR27Fr6M87YUkigFw5aZjqLlBftwrwAEOQNXI7RLTZenLYLQXVZ+yhVsCtbBi5E8gl8aao= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764407713; c=relaxed/simple; bh=pgcx3ngXjyLfVIMGgjFCoFd4kCXfwxRmHCPjPsuQ154=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=uNGlt5jQf09BObXGE6N+AD0OITUkmIFlg1NXYjEMcAFBo0KLqoDd00vdhPV20TimHlcIQrgnSF3scG6KULCOGH4Bxegvp1QZoqSDghRFeI2ClPH71PFNGrTlU48nZ3AxliHK9eoek/M9tO4yKOe2beNqBhqjOpp7bqySVrkAYRg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=TFvX1Iiu; arc=none smtp.client-ip=209.85.210.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TFvX1Iiu" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-7bc248dc16aso2135810b3a.0 for ; Sat, 29 Nov 2025 01:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764407711; x=1765012511; darn=lists.linux.dev; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=7McoraGzT7ft4cOd5uMMqzYD9akwWmQ1zJslTjyMrRg=; b=TFvX1IiuONMtD4BVidUW8OFis8364bCJI8VeuDsxL9cmRqOI1mhjsOGid+iBhaIgWp YDmgn4Jx/a+CiTJLDQtusUn6bDnhcXlESRSOYx5UNw+cBj5/1DQMMtcPx1iVyPRFh5bh OD+R7u+dRNR88tlannEYkRbmbh9rvblHlIEhfx4KZ2u7y/oTssgzUYpgmlDPLZL3/rzX kmauffRnvwUFKLxngIg10SqSyagXxAcDqh19joWJC+6Ye0Iyq99loS976SVPpbVcp8ig HfhqFv8lpTjuTs+7S2I4e/Vtbev6P/T0BkDL+iGZIPxLXLnjeSwQbhYPpOHKmORS2fbO 5e2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764407711; x=1765012511; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7McoraGzT7ft4cOd5uMMqzYD9akwWmQ1zJslTjyMrRg=; b=Q8mAq7M9IvqaFHfbPPsghEqfqUHpFFFvDDu3xa/37ld4+aR0CBfKs0FEOieMbWI7Af vMWY4oprQUaQRq84CtSNjO/J1KZQIFnN3+bQZi3qsDuo5emLh9Kk4tfOyZ+UFsatcKjm alJdlv8KRsGJ26d3PSGOuteegNG2vnK92ILUBCyi3dYDhMZxH1q6vTPQg8MuQ8Cj3smK dsG20gBjGC2F4GEZ732hbf/5hbYM7BQyv77UNi85dJkoZUfeVCW9hnsWRuSEaj0+zXIA L76BBI1K+hafG+POZi1xR1rHeekMf/Wvl7GGio68b3iJIas32gpWUEgYmXn/7dxLY5hY 4NUw== X-Forwarded-Encrypted: i=1; AJvYcCXW1H32Moav2NPEUpFfDzxqbH0QsxSsLOSskPOyiyM4ptwR0EifhXuz8opTdec7vyUhDzEZ@lists.linux.dev X-Gm-Message-State: AOJu0YxK9EPM1LguCNLOFw4uxeQth+9CAuY3/os1kvOzbpzmv4noJQGY ziqIQvDLqHjWKOtZF7xGASBzbbqvFAHynt17MGV59buFWMKdqN5OOodZ X-Gm-Gg: ASbGnct19NhxOUykJFMTA1H17jwE1P+APkV3zIyGISiiBgoGpanrln5veAbJ5LyHhm+ /XhZQ1/2Eh1Ta4yg+g4FTO9/Jb3RPnqxSjTqd2mQHrKufy6qJq6k+9IWdNBtwDmoH5u7R6GwSWz QFLm8RNGmt6CaWmbBGdXqa7cmdEHdbSbilC92RNYV+/MlEHmDB0WdgH7tQoAed+Twme+mqnRAl2 T3UJ0Vtnxb0DI4rSwR3XIMlPSxp2173Tp2i+d+XFykuOVqNZcGKz20A6hfXLQV8DLbNJDpKYyvs VRfcUM53mikslT1eZXybpCdBWr+z7S/vd21Q5LwZZVMXeYhvqfEiXqisPUZSjDUEBkWoonC8iOo UVaiCguALnFC+k2gkmbEDsMkfPK9ZgMFfLPjgFqtD12gdHCp5+2NMosirK25sJK7uGCHpGL/kd6 jchacVDEwP6tHLqqhP/b067Q== X-Google-Smtp-Source: AGHT+IHRggrtJjCz3r4/B4Ms7F3IdMI1ozOO7ePbM2mx3pzpr/8CuNAAHtPqxkceHn3Pt0+C0BkbHA== X-Received: by 2002:a05:6a00:2389:b0:7aa:bd80:f4db with SMTP id d2e1a72fcca58-7ca8740ec4cmr17210906b3a.5.1764407710531; Sat, 29 Nov 2025 01:15:10 -0800 (PST) Received: from fedora ([2405:201:3017:184:2d1c:8c4c:2945:3f7c]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7d15e7db416sm7300563b3a.41.2025.11.29.01.15.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Nov 2025 01:15:09 -0800 (PST) From: Bhavik Sachdev To: Alexander Viro , Christian Brauner , Shuah Khan Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, criu@lists.linux.dev, Jan Kara , Jeff Layton , Aleksa Sarai , Miklos Szeredi , Bhavik Sachdev , Pavel Tikhomirov , Andrei Vagin , Alexander Mikhalitsyn , John Hubbard , Amir Goldstein , "Martin K . Petersen" , Andrew Donnellan Subject: [PATCH v7 0/3] statmount: accept fd as a parameter Date: Sat, 29 Nov 2025 14:41:19 +0530 Message-ID: <20251129091455.757724-1-b.sachdev1904@gmail.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: criu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit We would like to add support for checkpoint/restoring file descriptors open on these "unmounted" mounts to CRIU (Checkpoint/Restore in Userspace) [1]. Currently, we have no way to get mount info for these "unmounted" mounts since they do appear in /proc//mountinfo and statmount does not work on them, since they do not belong to any mount namespace. This patch helps us by providing a way to get mountinfo for these "unmounted" mounts by using a fd on the mount. Changes from v6 [2] to v7: * Add kselftests for STATMOUNT_BY_FD flag. * Instead of renaming mnt_id_req.mnt_ns_fd to mnt_id_req.fd introduce a union so struct mnt_id_req looks like this: struct mnt_id_req { __u32 size; union { __u32 mnt_ns_fd; __u32 mnt_fd; }; __u64 mnt_id; __u64 param; __u64 mnt_ns_id; }; * In case of STATMOUNT_BY_FD grab mnt_ns inside of do_statmount(), since we get mnt_ns from mnt, which should happen under namespace lock. * Remove the modifications made to grab_requested_mnt_ns, those were never needed. Changes from v5 [3] to v6: * Instead of returning "[unmounted]" as the mount point for "unmounted" mounts, we unset the STATMOUNT_MNT_POINT flag in statmount.mask. * Instead of returning 0 as the mnt_ns_id for "unmounted" mounts, we unset the STATMOUNT_MNT_NS_ID flag in statmount.mask. * Added comment in `do_statmount` clarifying that the caller sets s->mnt in case of STATMOUNT_BY_FD. * In `do_statmount` move the mnt_ns_id and mnt_ns_empty() check just before lookup_mnt_in_ns(). * We took another look at the capability checks for getting information for "unmounted" mounts using an fd and decided to remove them for the following reasons: - All fs related information is available via fstatfs() without any capability check. - Mount information is also available via /proc/pid/mountinfo (without any capability check). - Given that we have access to a fd on the mount which tells us that we had access to the mount at some point (or someone that had access gave us the fd). So, we should be able to access mount info. Changes from v4 [4] to v5: Check only for s->root.mnt to be NULL instead of checking for both s->root.mnt and s->root.dentry (I did not find a case where only one of them would be NULL). * Only allow system root (CAP_SYS_ADMIN in init_user_ns) to call statmount() on fd's on "unmounted" mounts. We (mostly Pavel) spent some time thinking about how our previous approach (of checking the opener's file credentials) caused problems. Please take a look at the linked pictures they describe everything more clearly. Case 1: A fd is on a normal mount (Link to Picture: [5]) Consider, a situation where we have two processes P1 and P2 and a file F1. F1 is opened on mount ns M1 by P1. P1 is nested inside user namespace U1 and U2. P2 is also in U1. P2 is also in a pid namespace and mount namespace separate from M1. P1 sends F1 to P2 (using a unix socket). But, P2 is unable to call statmount() on F1 because since it is a separate pid and mount namespace. This is good and expected. Case 2: A fd is on a "unmounted" mount (Link to Picture: [6]) Consider a similar situation as Case 1. But now F1 is on a mounted that has been "unmounted". Now, since we used openers credentials to check for permissions P2 ends up having the ability call statmount() and get mount info for this "unmounted" mount. Hence, It is better to restrict the ability to call statmount() on fds on "unmounted" mounts to system root only (There could also be other cases than the one described above). Changes from v3 [7] to v4: * Change the string returned when there is no mountpoint to be "[unmounted]" instead of "[detached]". * Remove the new DEFINE_FREE put_file and use the one already present in include/linux/file.h (fput) [8]. * Inside listmount consistently pass 0 in flags to copy_mnt_id_req and prepare_klistmount()->grab_requested_mnt_ns() and remove flags from the prepare_klistmount prototype. * If STATMOUNT_BY_FD is set, check for mnt_ns_id == 0 && mnt_id == 0. Changes from v2 [9] to v3: * Rename STATMOUNT_FD flag to STATMOUNT_BY_FD. * Fixed UAF bug caused by the reference to fd_mount being bound by scope of CLASS(fd_raw, f)(kreq.fd) by using fget_raw instead. * Reused @spare parameter in mnt_id_req instead of adding new fields to the struct. Changes from v1 [10] to v2: v1 of this patchset, took a different approach and introduced a new umount_mnt_ns, to which "unmounted" mounts would be moved to (instead of their namespace being NULL) thus allowing them to be still available via statmount. Introducing umount_mnt_ns complicated namespace locking and modified performance sensitive code [11] and it was agreed upon that fd-based statmount would be better. This code is also available on github [12]. [1]: https://github.com/checkpoint-restore/criu/pull/2754 [2]: https://lore.kernel.org/all/20251118084836.2114503-1-b.sachdev1904@gmail.com/ [3]: https://lore.kernel.org/criu/20251109053921.1320977-2-b.sachdev1904@gmail.com/T/#u [4]: https://lore.kernel.org/all/20251029052037.506273-2-b.sachdev1904@gmail.com/ [5]: https://github.com/bsach64/linux/blob/statmount-fd-v5/fd_on_normal_mount.png [6]: https://github.com/bsach64/linux/blob/statmount-fd-v5/file_on_unmounted_mount.png [7]: https://lore.kernel.org/all/20251024181443.786363-1-b.sachdev1904@gmail.com/ [8]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/file.h#n97 [9]: https://lore.kernel.org/linux-fsdevel/20251011124753.1820802-1-b.sachdev1904@gmail.com/ [10]: https://lore.kernel.org/linux-fsdevel/20251002125422.203598-1-b.sachdev1904@gmail.com/ [11]: https://lore.kernel.org/linux-fsdevel/7e4d9eb5-6dde-4c59-8ee3-358233f082d0@virtuozzo.com/ [12]: https://github.com/bsach64/linux/tree/statmount-fd-v7 Bhavik Sachdev (3): statmount: permission check should return EPERM statmount: accept fd as a parameter selftests: statmount: tests for STATMOUNT_BY_FD fs/namespace.c | 102 ++++--- include/uapi/linux/mount.h | 10 +- .../filesystems/statmount/statmount.h | 15 +- .../filesystems/statmount/statmount_test.c | 261 +++++++++++++++++- .../filesystems/statmount/statmount_test_ns.c | 101 ++++++- 5 files changed, 430 insertions(+), 59 deletions(-) -- 2.52.0