All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <christian.brauner@ubuntu.com>
To: Gregory Farnum <gfarnum@redhat.com>
Cc: Jeff Layton <jlayton@kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	ceph-devel <ceph-devel@vger.kernel.org>,
	Ilya Dryomov <idryomov@gmail.com>, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 02/12] ceph: handle idmapped mounts in create_request_message()
Date: Wed, 5 Jan 2022 15:11:04 +0100	[thread overview]
Message-ID: <20220105141104.df6nqtqkahis55xa@wittgenstein> (raw)
In-Reply-To: <CAJ4mKGbKVcvoYGi3go3-VtMhjXES5iMyof9qMfL+8AyHiPKBNA@mail.gmail.com>

On Tue, Jan 04, 2022 at 11:33:33AM -0800, Gregory Farnum wrote:
> On Tue, Jan 4, 2022 at 9:41 AM Jeff Layton <jlayton@kernel.org> wrote:
> >
> > On Tue, 2022-01-04 at 15:04 +0100, Christian Brauner wrote:
> > > From: Christian Brauner <christian.brauner@ubuntu.com>
> > >
> > > Inode operations that create a new filesystem object such as ->mknod,
> > > ->create, ->mkdir() and others don't take a {g,u}id argument explicitly.
> > > Instead the caller's fs{g,u}id is used for the {g,u}id of the new
> > > filesystem object.
> > >
> > > Cephfs mds creation request argument structures mirror this filesystem
> > > behavior. They don't encode a {g,u}id explicitly. Instead the caller's
> > > fs{g,u}id that is always sent as part of any mds request is used by the
> > > servers to set the {g,u}id of the new filesystem object.
> > >
> > > In order to ensure that the correct {g,u}id is used map the caller's
> > > fs{g,u}id for creation requests. This doesn't require complex changes.
> > > It suffices to pass in the relevant idmapping recorded in the request
> > > message. If this request message was triggered from an inode operation
> > > that creates filesystem objects it will have passed down the relevant
> > > idmaping. If this is a request message that was triggered from an inode
> > > operation that doens't need to take idmappings into account the initial
> > > idmapping is passed down which is an identity mapping and thus is
> > > guaranteed to leave the caller's fs{g,u}id unchanged.,u}id is sent.
> > >
> > > The last few weeks before Christmas 2021 I have spent time not just
> > > reading and poking the cephfs kernel code but also took a look at the
> > > ceph mds server userspace to ensure I didn't miss some subtlety.
> > >
> > > This made me aware of one complication to solve. All requests send the
> > > caller's fs{g,u}id over the wire. The caller's fs{g,u}id matters for the
> > > server in exactly two cases:
> > >
> > > 1. to set the ownership for creation requests
> > > 2. to determine whether this client is allowed access on this server
> > >
> > > Case 1. we already covered and explained. Case 2. is only relevant for
> > > servers where an explicit uid access restriction has been set. That is
> > > to say the mds server restricts access to requests coming from a
> > > specific uid. Servers without uid restrictions will grant access to
> > > requests from any uid by setting MDS_AUTH_UID_ANY.
> > >
> > > Case 2. introduces the complication because the caller's fs{g,u}id is
> > > not just used to record ownership but also serves as the {g,u}id used
> > > when checking access to the server.
> > >
> > > Consider a user mounting a cephfs client and creating an idmapped mount
> > > from it that maps files owned by uid 1000 to be owned uid 0:
> > >
> > > mount -t cephfs -o [...] /unmapped
> > > mount-idmapped --map-mount 1000:0:1 /idmapped
> > >
> > > That is to say if the mounted cephfs filesystem contains a file "file1"
> > > which is owned by uid 1000:
> > >
> > > - looking at it via /unmapped/file1 will report it as owned by uid 1000
> > >   (One can think of this as the on-disk value.)
> > > - looking at it via /idmapped/file1 will report it as owned by uid 0
> > >
> > > Now, consider creating new files via the idmapped mount at /idmapped.
> > > When a caller with fs{g,u}id 1000 creates a file "file2" by going
> > > through the idmapped mount mounted at /idmapped it will create a file
> > > that is owned by uid 1000 on-disk, i.e.:
> > >
> > > - looking at it via /unmapped/file2 will report it as owned by uid 1000
> > > - looking at it via /idmapped/file2 will report it as owned by uid 0
> > >
> > > Now consider an mds server that has a uid access restriction set and
> > > only grants access to requests from uid 0.
> > >
> > > If the client sends a creation request for a file e.g. /idmapped/file2
> > > it will send the caller's fs{g,u}id idmapped according to the idmapped
> > > mount. So if the caller has fs{g,u}id 1000 it will be mapped to {g,u}id
> > > 0 in the idmapped mount and will be sent over the wire allowing the
> > > caller access to the mds server.
> > >
> > > However, if the caller is not issuing a creation request the caller's
> > > fs{g,u}id will be send without the mount's idmapping applied. So if the
> > > caller that just successfully created a new file on the restricted mds
> > > server sends a request as fs{g,u}id 1000 access will be refused. This
> > > however is inconsistent.
> > >
> >
> > IDGI, why would you send the fs{g,u}id without the mount's idmapping
> > applied in this case? ISTM that idmapping is wholly a client-side
> > feature, and that you should always map id's regardless of whether
> > you're creating or not.
> 
> Yeah, I'm confused. We want the fs {g,u}id to be consistent throughout
> the request pipeline and to reflect the actual Ceph user all the way
> through the server-side pipeline. What if client.greg is only
> authorized to work as uid 12345 and access /users/greg/; why would you
> send in a bunch of requests as root just because I mounted that way
> inside my own space?
> 
> This might be more obvious in the userspace Client, which is already
> set up to be friendlier to mapped users for Ganesha etc:
> mknod (https://github.com/ceph/ceph/blob/master/src/client/Client.cc#L7297)
> and similar calls receive a "UserPerm" from the caller specifying who
> the call should be performed as, and they pass that in to the generic
> make_requst() function
> (https://github.com/ceph/ceph/blob/master/src/client/Client.cc#L1778)
> which uses it to set the uid and gid fields you found in the message.

Thank you for those links. I think I read through this code before and
I'll give it another read.

  reply	other threads:[~2022-01-05 14:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 14:04 [PATCH 00/12] ceph: support idmapped mounts Christian Brauner
2022-01-04 14:04 ` [PATCH 01/12] ceph: stash idmapping in mdsc request Christian Brauner
2022-01-04 17:22   ` Jeff Layton
2022-01-04 14:04 ` [PATCH 02/12] ceph: handle idmapped mounts in create_request_message() Christian Brauner
2022-01-04 17:40   ` Jeff Layton
2022-01-04 19:33     ` Gregory Farnum
2022-01-05 14:11       ` Christian Brauner [this message]
2022-01-05 14:10     ` Christian Brauner
2022-01-05 15:03       ` Jeff Layton
2022-01-05 15:35         ` Christian Brauner
2022-01-04 14:04 ` [PATCH 03/12] ceph: allow idmapped mknod inode op Christian Brauner
2022-01-04 14:04 ` [PATCH 04/12] ceph: allow idmapped symlink " Christian Brauner
2022-01-04 14:04 ` [PATCH 05/12] ceph: allow idmapped mkdir " Christian Brauner
2022-01-04 14:04 ` [PATCH 06/12] ceph: allow idmapped rename " Christian Brauner
2022-01-04 14:04 ` [PATCH 07/12] ceph: allow idmapped getattr " Christian Brauner
2022-01-04 14:04 ` [PATCH 08/12] ceph: allow idmapped permission " Christian Brauner
2022-01-04 14:04 ` [PATCH 09/12] ceph: allow idmapped setattr " Christian Brauner
2022-01-04 14:04 ` [PATCH 10/12] ceph/acl: allow idmapped set_acl " Christian Brauner
2022-01-04 14:04 ` [PATCH 11/12] ceph/file: allow idmapped atomic_open " Christian Brauner
2022-01-04 14:04 ` [PATCH 12/12] ceph: allow idmapped mounts Christian Brauner

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=20220105141104.df6nqtqkahis55xa@wittgenstein \
    --to=christian.brauner@ubuntu.com \
    --cc=brauner@kernel.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=gfarnum@redhat.com \
    --cc=hch@lst.de \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --subject='Re: [PATCH 02/12] ceph: handle idmapped mounts in create_request_message()' \
    /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

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.