From: Christian Brauner <brauner@kernel.org>
To: Erin Shepherd <erin.shepherd@e43.eu>,
Amir Goldstein <amir73il@gmail.com>,
Jeff Layton <jlayton@kernel.org>
Cc: Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
Chuck Lever <chuck.lever@oracle.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nfs@vger.kernel.org
Subject: [PATCH RFC 0/2] pidfs: file handle preliminaries
Date: Thu, 28 Nov 2024 13:33:36 +0100 [thread overview]
Message-ID: <20241128-work-pidfs-v1-0-80f267639d98@kernel.org> (raw)
In-Reply-To: <20241114-fragt-rohre-28b21496ecbc@brauner>
Hey,
This reworks the inode number allocation for pidfs in order to support
file handles properly.
Recently we received a patchset that aims to enable file handle encoding
and decoding via name_to_handle_at(2) and open_by_handle_at(2).
A crucical step in the patch series is how to go from inode number to
struct pid without leaking information into unprivileged contexts. The
issue is that in order to find a struct pid the pid number in the
initial pid namespace must be encoded into the file handle via
name_to_handle_at(2). This can be used by containers using a separate
pid namespace to learn what the pid number of a given process in the
initial pid namespace is. While this is a weak information leak it could
be used in various exploits and in general is an ugly wart in the
design.
To solve this problem a new way is needed to lookup a struct pid based
on the inode number allocated for that struct pid. The other part is to
remove the custom inode number allocation on 32bit systems that is also
an ugly wart that should go away.
So, a new scheme is used that I was discusssing with Tejun some time
back. A cyclic ida is used for the lower 32 bits and a the high 32 bits
are used for the generation number. This gives a 64 bit inode number
that is unique on both 32 bit and 64 bit. The lower 32 bit number is
recycled slowly and can be used to lookup struct pids.
So after applying the pidfs file handle series at
https://lore.kernel.org/r/20241101135452.19359-1-erin.shepherd@e43.eu on
top of the patches here we should be able to simplify encoding and
decoding to something like:
diff --git a/fs/pidfs.c b/fs/pidfs.c
index e71294d3d607..a38b833a2d38 100644
--- a/fs/pidfs.c
+++ b/fs/pidfs.c
@@ -78,7 +78,7 @@ void pidfs_remove_pid(struct pid *pid)
}
/* Find a struct pid based on the inode number. */
-static __maybe_unused struct pid *pidfs_ino_get_pid(u64 ino)
+static struct pid *pidfs_ino_get_pid(u64 ino)
{
ino_t pid_ino = pidfs_ino(ino);
u32 gen = pidfs_gen(ino);
@@ -475,49 +475,37 @@ static const struct dentry_operations pidfs_dentry_operations = {
.d_prune = stashed_dentry_prune,
};
-#define PIDFD_FID_LEN 3
-
-struct pidfd_fid {
- u64 ino;
- s32 pid;
-} __packed;
-
-static int pidfs_encode_fh(struct inode *inode, u32 *fh, int *max_len,
+static int pidfs_encode_fh(struct inode *inode, __u32 *fh, int *max_len,
struct inode *parent)
{
struct pid *pid = inode->i_private;
- struct pidfd_fid *fid = (struct pidfd_fid *)fh;
- if (*max_len < PIDFD_FID_LEN) {
- *max_len = PIDFD_FID_LEN;
+ if (*max_len < 2) {
+ *max_len = 2;
return FILEID_INVALID;
}
- fid->ino = pid->ino;
- fid->pid = pid_nr(pid);
- *max_len = PIDFD_FID_LEN;
+ *max_len = 2;
+ *(u64 *)fh = pid->ino;
return FILEID_INO64_GEN;
}
static struct dentry *pidfs_fh_to_dentry(struct super_block *sb,
- struct fid *gen_fid,
+ struct fid *fid,
int fh_len, int fh_type)
{
int ret;
struct path path;
- struct pidfd_fid *fid = (struct pidfd_fid *)gen_fid;
struct pid *pid;
+ u64 pid_ino;
- if (fh_type != FILEID_INO64_GEN || fh_len < PIDFD_FID_LEN)
+ if (fh_type != FILEID_INO64_GEN || fh_len < 2)
return NULL;
- scoped_guard(rcu) {
- pid = find_pid_ns(fid->pid, &init_pid_ns);
- if (!pid || pid->ino != fid->ino || pid_vnr(pid) == 0)
- return NULL;
-
- pid = get_pid(pid);
- }
+ pid_ino = *(u64 *)fid;
+ pid = pidfs_ino_get_pid(pid_ino);
+ if (!pid)
+ return NULL;
ret = path_from_stashed(&pid->stashed, pidfs_mnt, pid, &path);
if (ret < 0)
Thanks!
Christian
---
Christian Brauner (2):
pidfs: rework inode number allocation
pidfs: remove 32bit inode number handling
fs/pidfs.c | 138 +++++++++++++++++++++++++++++++++++---------------
include/linux/pidfs.h | 2 +
kernel/pid.c | 11 ++--
3 files changed, 103 insertions(+), 48 deletions(-)
---
base-commit: b86545e02e8c22fb89218f29d381fa8e8b91d815
change-id: 20241128-work-pidfs-2bd42c7ea772
next prev parent reply other threads:[~2024-11-28 12:34 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-01 13:54 [PATCH 0/4] pidfs: implement file handle support Erin Shepherd
2024-11-01 13:54 ` [PATCH 1/4] pseudofs: add support for export_ops Erin Shepherd
2024-11-12 15:56 ` Amir Goldstein
2024-11-01 13:54 ` [PATCH 2/4] pidfs: implement file handle export support Erin Shepherd
2024-11-12 15:55 ` Amir Goldstein
2024-11-01 13:54 ` [PATCH 3/4] pid: introduce find_get_pid_ns Erin Shepherd
2024-11-12 15:59 ` Amir Goldstein
2024-11-01 13:54 ` [PATCH 4/4] pidfs: implement fh_to_dentry Erin Shepherd
2024-11-12 16:33 ` Amir Goldstein
2024-11-12 23:51 ` Jeff Layton
2024-11-13 8:01 ` Amir Goldstein
2024-11-13 10:11 ` Erin Shepherd
2024-11-13 12:21 ` Christian Brauner
2024-11-13 12:09 ` Christian Brauner
2024-11-13 13:06 ` Erin Shepherd
2024-11-13 13:26 ` Christian Brauner
2024-11-13 13:48 ` Erin Shepherd
2024-11-14 10:29 ` Christian Brauner
2024-11-14 12:21 ` Erin Shepherd
2024-11-12 13:10 ` [PATCH 0/4] pidfs: implement file handle support Christian Brauner
2024-11-12 13:57 ` Jeff Layton
2024-11-12 22:43 ` Erin Shepherd
2024-11-13 0:37 ` Darrick J. Wong
2024-11-13 11:35 ` Christian Brauner
2024-11-13 17:55 ` [PATCH v2 0/3] " Erin Shepherd
2024-11-13 17:55 ` [PATCH v2 1/3] pseudofs: add support for export_ops Erin Shepherd
2024-11-13 17:55 ` [PATCH v2 2/3] exportfs: allow fs to disable CAP_DAC_READ_SEARCH check Erin Shepherd
2024-11-13 22:50 ` kernel test robot
2024-11-14 1:29 ` kernel test robot
2024-11-14 4:37 ` Christoph Hellwig
2024-11-14 12:56 ` Erin Shepherd
2024-11-14 6:37 ` Amir Goldstein
2024-11-14 14:16 ` Christian Brauner
2024-11-13 17:55 ` [PATCH v2 3/3] pidfs: implement file handle support Erin Shepherd
2024-11-14 7:07 ` Amir Goldstein
2024-11-14 12:42 ` Erin Shepherd
2024-11-14 12:52 ` Christian Brauner
2024-11-14 13:13 ` Erin Shepherd
2024-11-14 14:13 ` Christian Brauner
2024-11-14 21:52 ` Erin Shepherd
2024-11-15 7:50 ` Amir Goldstein
2024-11-14 7:02 ` [PATCH v2 0/3] " Amir Goldstein
2024-11-14 12:48 ` Erin Shepherd
2024-11-14 14:27 ` Christian Brauner
2024-11-28 12:33 ` Christian Brauner [this message]
2024-11-28 12:33 ` [PATCH RFC 1/2] pidfs: rework inode number allocation Christian Brauner
2024-11-28 17:19 ` Amir Goldstein
2024-11-28 12:33 ` [PATCH RFC 2/2] pidfs: remove 32bit inode number handling Christian Brauner
2024-11-28 17:06 ` [PATCH RFC 0/2] pidfs: file handle preliminaries Amir Goldstein
2024-11-14 16:10 ` [PATCH v2 0/3] pidfs: implement file handle support Amir Goldstein
2024-11-12 23:03 ` [PATCH 0/4] " Erin Shepherd
2024-11-13 0:40 ` Darrick J. Wong
2024-11-13 10:17 ` Erin Shepherd
2024-11-13 13:29 ` Jeff Layton
2024-11-13 14:41 ` Chuck Lever III
2024-11-14 10:39 ` Christian Brauner
2024-11-14 6:55 ` Amir Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241128-work-pidfs-v1-0-80f267639d98@kernel.org \
--to=brauner@kernel.org \
--cc=amir73il@gmail.com \
--cc=chuck.lever@oracle.com \
--cc=erin.shepherd@e43.eu \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox