From: Jeff Layton <jlayton@kernel.org>
To: Christian Brauner <brauner@kernel.org>,
Erin Shepherd <erin.shepherd@e43.eu>,
Amir Goldstein <amir73il@gmail.com>
Cc: 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: Re: [PATCH RFC v2 0/3] pidfs: file handle preliminaries
Date: Fri, 29 Nov 2024 09:27:35 -0500 [thread overview]
Message-ID: <5ff149339540d3bccb09eb30544fab35ea29a53f.camel@kernel.org> (raw)
In-Reply-To: <20241129-work-pidfs-v2-0-61043d66fbce@kernel.org>
On Fri, 2024-11-29 at 14:02 +0100, Christian Brauner wrote:
> 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.
>
> Thanks!
> Christian
>
> ---
> Changes in v2:
> - Remove __maybe_unused pidfd_ino_get_pid() function that was only there
> for initial illustration purposes.
> - Link to v1: https://lore.kernel.org/r/20241128-work-pidfs-v1-0-80f267639d98@kernel.org
>
> ---
> Christian Brauner (3):
> pidfs: rework inode number allocation
> pidfs: remove 32bit inode number handling
> pidfs: support FS_IOC_GETVERSION
>
> fs/pidfs.c | 118 ++++++++++++++++++++++++++++++++------------------
> include/linux/pidfs.h | 2 +
> kernel/pid.c | 14 +++---
> 3 files changed, 86 insertions(+), 48 deletions(-)
> ---
> base-commit: b86545e02e8c22fb89218f29d381fa8e8b91d815
> change-id: 20241128-work-pidfs-2bd42c7ea772
>
>
This seems like a good stopgap fix until we can sort out how to get to
64-bit inode numbers internally everywhere.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2024-11-29 14:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-29 13:02 [PATCH RFC v2 0/3] pidfs: file handle preliminaries Christian Brauner
2024-11-29 13:02 ` [PATCH RFC v2 1/3] pidfs: rework inode number allocation Christian Brauner
2024-12-02 15:15 ` Jan Kara
2024-11-29 13:02 ` [PATCH RFC v2 2/3] pidfs: remove 32bit inode number handling Christian Brauner
2024-12-02 15:18 ` Jan Kara
2024-11-29 13:02 ` [PATCH RFC v2 3/3] pidfs: support FS_IOC_GETVERSION Christian Brauner
2024-12-02 15:35 ` Jan Kara
2024-11-29 13:37 ` [PATCH RFC 0/6] pidfs: implement file handle support Christian Brauner
2024-11-29 13:38 ` [PATCH RFC 1/6] pseudofs: add support for export_ops Christian Brauner
2024-12-02 15:59 ` Jan Kara
2024-11-29 13:38 ` [PATCH RFC 2/6] fhandle: simplify error handling Christian Brauner
2024-12-02 15:58 ` Jan Kara
2024-11-29 13:38 ` [PATCH RFC 3/6] exportfs: add open method Christian Brauner
2024-12-02 16:05 ` Jan Kara
2024-11-29 13:38 ` [PATCH RFC 4/6] fhandle: pull CAP_DAC_READ_SEARCH check into may_decode_fh() Christian Brauner
2024-12-02 16:01 ` Jan Kara
2024-11-29 13:38 ` [PATCH RFC 5/6] exportfs: add permission method Christian Brauner
2024-12-02 16:04 ` Jan Kara
2024-11-29 13:38 ` [PATCH RFC 6/6] pidfs: implement file handle support Christian Brauner
2024-11-29 14:52 ` Amir Goldstein
2024-11-30 12:22 ` [PATCH RFC 0/6] " Amir Goldstein
2024-12-01 8:43 ` Christian Brauner
2024-12-01 12:09 ` Amir Goldstein
2024-12-01 12:44 ` Christian Brauner
2024-11-29 14:27 ` Jeff Layton [this message]
2024-11-29 14:34 ` [PATCH RFC v2 0/3] pidfs: file handle preliminaries 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=5ff149339540d3bccb09eb30544fab35ea29a53f.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=erin.shepherd@e43.eu \
--cc=jack@suse.cz \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.