linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xiubo Li <xiubli@redhat.com>
To: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Cc: Gregory Farnum <gfarnum@redhat.com>,
	Christian Brauner <brauner@kernel.org>,
	stgraber@ubuntu.com, linux-fsdevel@vger.kernel.org,
	Ilya Dryomov <idryomov@gmail.com>,
	Jeff Layton <jlayton@kernel.org>,
	ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 00/14] ceph: support idmapped mounts
Date: Mon, 26 Jun 2023 10:12:39 +0800	[thread overview]
Message-ID: <4c4f73d8-8238-6ab8-ae50-d83c1441ac05@redhat.com> (raw)
In-Reply-To: <CAEivzxeF51ZEKhQ-0M35nooZ7_cZgk1-q75-YbkeWpZ9RuHG4A@mail.gmail.com>


On 6/24/23 15:11, Aleksandr Mikhalitsyn wrote:
> On Sat, Jun 24, 2023 at 3:37 AM Xiubo Li <xiubli@redhat.com> wrote:
>> [...]
>>
>>   > > >
>>   > > > I thought about this too and came to the same conclusion, that
>> UID/GID
>>   > > > based
>>   > > > restriction can be applied dynamically, so detecting it on mount-time
>>   > > > helps not so much.
>>   > > >
>>   > > For this you please raise one PR to ceph first to support this, and in
>>   > > the PR we can discuss more for the MDS auth caps. And after the PR
>>   > > getting merged then in this patch series you need to check the
>>   > > corresponding option or flag to determine whether could the idmap
>>   > > mounting succeed.
>>   >
>>   > I'm sorry but I don't understand what we want to support here. Do we
>> want to
>>   > add some new ceph request that allows to check if UID/GID-based
>>   > permissions are applied for
>>   > a particular ceph client user?
>>
>> IMO we should prevent user to set UID/GID-based permisions caps from
>> ceph side.
>>
>> As I know currently there is no way to prevent users to set MDS auth
>> caps, IMO in ceph side at least we need one flag or option to disable
>> this once users want this fs cluster sever for idmap mounts use case.
> How this should be visible from the user side? We introducing a new
> kernel client mount option,
> like "nomdscaps", then pass flag to the MDS and MDS should check that
> MDS auth permissions
> are not applied (on the mount time) and prevent them from being
> applied later while session is active. Like that?
>
> At the same time I'm thinking about protocol extension that adds 2
> additional fields for UID/GID. This will allow to correctly
> handle everything. I wanted to avoid any changes to the protocol or
> server-side things. But if we want to change MDS side,
> maybe it's better then to go this way?

There is another way:

For each client it will have a dedicated client auth caps, something like:

client.foo
   key: *key*
   caps: [mds] allow r, allow rw path=/bar
   caps: [mon] allow r
   caps: [osd] allow rw tag cephfs data=cephfs_a

When mounting this client with idmap enabled, then we can just check the 
above [mds] caps, if there has any UID/GID based permissions set, then 
fail the mounting.

That means this kind client couldn't be mounted with idmap enabled.

Also we need to make sure that once there is a mount with idmap enabled, 
the corresponding client caps couldn't be append the UID/GID based 
permissions. This need a patch in ceph anyway IMO.

Thanks

- Xiubo





>
> Thanks,
> Alex
>
>> Thanks
>>
>> - Xiubo
>>


  reply	other threads:[~2023-06-26  2:13 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-08 15:42 [PATCH v5 00/14] ceph: support idmapped mounts Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 01/14] fs: export mnt_idmap_get/mnt_idmap_put Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 02/14] ceph: stash idmapping in mdsc request Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 03/14] ceph: handle idmapped mounts in create_request_message() Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 04/14] ceph: pass an idmapping to mknod/symlink/mkdir/rename Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 05/14] ceph: allow idmapped getattr inode op Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 06/14] ceph: allow idmapped permission " Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 07/14] ceph: pass idmap to __ceph_setattr Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 08/14] ceph: allow idmapped setattr inode op Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 09/14] ceph/acl: allow idmapped set_acl " Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 10/14] ceph/file: allow idmapped atomic_open " Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 11/14] ceph: pass idmap to ceph_do_getattr Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 12/14] ceph: pass idmap to __ceph_setxattr Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 13/14] ceph: pass idmap to ceph_open/ioctl_set_layout Alexander Mikhalitsyn
2023-06-08 15:42 ` [PATCH v5 14/14] ceph: allow idmapped mounts Alexander Mikhalitsyn
2023-06-09  1:57 ` [PATCH v5 00/14] ceph: support " Xiubo Li
2023-06-09  8:59   ` Aleksandr Mikhalitsyn
2023-06-09  9:59     ` Christian Brauner
2023-06-09 10:12       ` Aleksandr Mikhalitsyn
2023-06-13  1:43         ` Xiubo Li
2023-06-13 12:46           ` Aleksandr Mikhalitsyn
2023-06-14  9:45             ` Christian Brauner
2023-06-13 14:53           ` Gregory Farnum
2023-06-13 16:27             ` Aleksandr Mikhalitsyn
2023-06-14  1:52             ` Xiubo Li
2023-06-14 12:39               ` Aleksandr Mikhalitsyn
     [not found]               ` <CAEivzxcr99sERxZX17rZ5jW9YSzAWYvAjOOhBH+FqRoso2=yng@mail.gmail.com>
2023-06-15  5:08                 ` Xiubo Li
2023-06-15 11:05                   ` Aleksandr Mikhalitsyn
2023-06-15 12:29                   ` Xiubo Li
2023-06-15 12:54                     ` Aleksandr Mikhalitsyn
2023-06-21 16:55                       ` Aleksandr Mikhalitsyn
2023-06-26  1:04                       ` Xiubo Li
2023-06-24  1:36                   ` Xiubo Li
2023-06-24  7:11                     ` Aleksandr Mikhalitsyn
2023-06-26  2:12                       ` Xiubo Li [this message]
2023-06-26 11:23                         ` Aleksandr Mikhalitsyn
2023-06-26 11:49                           ` Aleksandr Mikhalitsyn
2023-07-04  1:10                             ` Xiubo Li
2023-07-04  1:08                           ` Xiubo Li
2023-07-14 12:57                             ` Aleksandr Mikhalitsyn
2023-07-18  1:44                               ` Xiubo Li
2023-07-18 14:49                                 ` Aleksandr Mikhalitsyn
2023-07-19 11:57                                   ` Aleksandr Mikhalitsyn
2023-07-20  6:36                                     ` Xiubo Li
2023-07-20  6:41                                       ` Aleksandr Mikhalitsyn
2023-07-21 15:43                                       ` Aleksandr Mikhalitsyn
2023-07-24  1:02                                         ` Xiubo Li

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=4c4f73d8-8238-6ab8-ae50-d83c1441ac05@redhat.com \
    --to=xiubli@redhat.com \
    --cc=aleksandr.mikhalitsyn@canonical.com \
    --cc=brauner@kernel.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=gfarnum@redhat.com \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stgraber@ubuntu.com \
    /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;
as well as URLs for NNTP newsgroup(s).