public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
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>

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox