linux.git/fs/fhandle.c, branch v6.17

fhandle: use more consistent rules for decoding file handle from userns

2025-08-29T07:48:31+00:00

Commit 620c266f39493 ("fhandle: relax open_by_handle_at() permission
checks") relaxed the coditions for decoding a file handle from non init
userns.

The conditions are that that decoded dentry is accessible from the user
provided mountfd (or to fs root) and that all the ancestors along the
path have a valid id mapping in the userns.

These conditions are intentionally more strict than the condition that
the decoded dentry should be "lookable" by path from the mountfd.

For example, the path /home/amir/dir/subdir is lookable by path from
unpriv userns of user amir, because /home perms is 755, but the owner of
/home does not have a valid id mapping in unpriv userns of user amir.

The current code did not check that the decoded dentry itself has a
valid id mapping in the userns.  There is no security risk in that,
because that final open still performs the needed permission checks,
but this is inconsistent with the checks performed on the ancestors,
so the behavior can be a bit confusing.

Add the check for the decoded dentry itself, so that the entire path,
including the last component has a valid id mapping in the userns.

Fixes: 620c266f39493 ("fhandle: relax open_by_handle_at() permission checks")
Signed-off-by: Amir Goldstein 
Link: https://lore.kernel.org/20250827194309.1259650-1-amir73il@gmail.com
Signed-off-by: Christian Brauner

fhandle: do_handle_open() should get FD with user flags

2025-08-15T13:46:57+00:00

In f07c7cc4684a, do_handle_open() was switched to use the automatic
cleanup method for getting a FD. In that change it was also switched
to pass O_CLOEXEC unconditionally to get_unused_fd_flags() instead
of passing the user-specified flags.

I don't see anything in that commit description that indicates this was
intentional, so I am assuming it was an oversight.

With this fix, the FD will again be opened with, or without, O_CLOEXEC
according to what the user requested.

Fixes: f07c7cc4684a ("fhandle: simplify error handling")
Signed-off-by: Thomas Bertschinger 
Link: https://lore.kernel.org/20250814235431.995876-4-tahbertschinger@gmail.com
Reviewed-by: Amir Goldstein 
Signed-off-by: Christian Brauner

fold fs_struct->{lock,seq} into a seqlock

2025-07-08T08:25:19+00:00

	The combination of spinlock_t lock and seqcount_spinlock_t seq
in struct fs_struct is an open-coded seqlock_t (see linux/seqlock_types.h).
	Combine and switch to equivalent seqlock_t primitives.  AFAICS,
that does end up with the same sequence of underlying operations in all
cases.
	While we are at it, get_fs_pwd() is open-coded verbatim in
get_path_from_fd(); rather than applying conversion to it, replace with
the call of get_fs_pwd() there.  Not worth splitting the commit for that,
IMO...

	A bit of historical background - conversion of seqlock_t to
use of seqcount_spinlock_t happened several months after the same
had been done to struct fs_struct; switching fs_struct to seqlock_t
could've been done immediately after that, but it looks like nobody
had gotten around to that until now.

Signed-off-by: Al Viro 
Link: https://lore.kernel.org/20250702053437.GC1880847@ZenIV
Acked-by: Ahmed S. Darwish 
Acked-by: Peter Zijlstra (Intel) 
Reviewed-by: Christian Brauner 
Signed-off-by: Christian Brauner

fhandle, pidfs: support open_by_handle_at() purely based on file handle

2025-06-24T15:02:05+00:00

Various filesystems such as pidfs (and likely drm in the future) have a
use-case to support opening files purely based on the handle without
having to require a file descriptor to another object. That's especially
the case for filesystems that don't do any lookup whatsoever and there's
zero relationship between the objects. Such filesystems are also
singletons that stay around for the lifetime of the system meaning that
they can be uniquely identified and accessed purely based on the file
handle type. Enable that so that userspace doesn't have to allocate an
object needlessly especially if they can't do that for whatever reason.

Link: https://lore.kernel.org/20250624-work-pidfs-fhandle-v2-10-d02a04858fe3@kernel.org
Reviewed-by: Jan Kara 
Reviewed-by: Amir Goldstein 
Signed-off-by: Christian Brauner

fhandle: reflow get_path_anchor()

2025-06-24T13:45:37+00:00

Switch to a more common coding style.

Link: https://lore.kernel.org/20250624-work-pidfs-fhandle-v2-5-d02a04858fe3@kernel.org
Reviewed-by: Jan Kara 
Reviewed-by: Amir Goldstein 
Signed-off-by: Christian Brauner

fhandle: rename to get_path_anchor()

2025-06-24T11:00:09+00:00

Rename as we're going to expand the function in the next step. The path
just serves as the anchor tying the decoding to the filesystem.

Link: https://lore.kernel.org/20250624-work-pidfs-fhandle-v2-3-d02a04858fe3@kernel.org
Reviewed-by: Jan Kara 
Reviewed-by: Amir Goldstein 
Signed-off-by: Christian Brauner

fhandle: hoist copy_from_user() above get_path_from_fd()

2025-06-24T11:00:09+00:00

In follow-up patches we need access to @file_handle->handle_type
before we start caring about get_path_from_fd().

Link: https://lore.kernel.org/20250624-work-pidfs-fhandle-v2-2-d02a04858fe3@kernel.org
Reviewed-by: Jan Kara 
Reviewed-by: Amir Goldstein 
Signed-off-by: Christian Brauner

fhandle: raise FILEID_IS_DIR in handle_type

2025-06-24T11:00:09+00:00

Currently FILEID_IS_DIR is raised in fh_flags which is wrong.
Raise it in handle->handle_type were it's supposed to be.

Link: https://lore.kernel.org/20250624-work-pidfs-fhandle-v2-1-d02a04858fe3@kernel.org
Fixes: c374196b2b9f ("fs: name_to_handle_at() support for "explicit connectable" file handles")
Reviewed-by: Jan Kara 
Reviewed-by: Amir Goldstein 
Cc: stable@kernel.org
Signed-off-by: Christian Brauner

exportfs: add permission method

2024-12-17T08:16:11+00:00

This allows filesystems such as pidfs to provide their custom permission
checks.

Link: https://lore.kernel.org/r/20241129-work-pidfs-file_handle-v1-5-87d803a42495@kernel.org
Reviewed-by: Amir Goldstein 
Reviewed-by: Jan Kara 
Signed-off-by: Christian Brauner

fhandle: pull CAP_DAC_READ_SEARCH check into may_decode_fh()

2024-12-14T11:40:41+00:00

There's no point in keeping it outside of that helper. This way we have
all the permission pieces in one place.

Link: https://lore.kernel.org/r/20241129-work-pidfs-file_handle-v1-4-87d803a42495@kernel.org
Reviewed-by: Amir Goldstein 
Reviewed-by: Jan Kara 
Signed-off-by: Christian Brauner