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: Tue, 4 Jul 2023 09:10:22 +0800 [thread overview]
Message-ID: <f885fddd-d511-0e31-cafe-b766144e6207@redhat.com> (raw)
In-Reply-To: <CAEivzxeBNOeufOraU27Y+qVApVjAoLhzwPnw0HSkqSt6P3MV9w@mail.gmail.com>
On 6/26/23 19:49, Aleksandr Mikhalitsyn wrote:
> On Mon, Jun 26, 2023 at 1:23 PM Aleksandr Mikhalitsyn
> <aleksandr.mikhalitsyn@canonical.com> wrote:
>> On Mon, Jun 26, 2023 at 4:12 AM Xiubo Li <xiubli@redhat.com> wrote:
>>>
>>> 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?
>> Hi Xiubo,
>>
>>> 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
>> Do we have any infrastructure to get this caps list on the client side
>> right now?
>> (I've taken a quick look through the code and can't find anything
>> related to this.)
> I've found your PR that looks related https://github.com/ceph/ceph/pull/48027
Yeah, after this we need to do some extra work in kclient and then it
will be easy to check the caps I think.
Thanks
- Xiubo
>>> 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.
>> understood
>>
>>> 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.
>> So, yeah we will need to effectively block cephx permission changes if
>> there is a client mounted with
>> an active idmapped mount. Sounds as something that require massive
>> changes on the server side.
>>
>> At the same time this will just block users from using idmapped mounts
>> along with UID/GID restrictions.
>>
>> If you want me to change server-side anyways, isn't it better just to
>> extend cephfs protocol to properly
>> handle UID/GIDs with idmapped mounts? (It was originally proposed by Christian.)
>> What we need to do here is to add a separate UID/GID fields for ceph
>> requests those are creating a new inodes
>> (like mknod, symlink, etc).
>>
>> Kind regards,
>> Alex
>>
>>> Thanks
>>>
>>> - Xiubo
>>>
>>>
>>>
>>>
>>>
>>>> Thanks,
>>>> Alex
>>>>
>>>>> Thanks
>>>>>
>>>>> - Xiubo
>>>>>
next prev parent reply other threads:[~2023-07-04 1:11 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
2023-06-26 11:23 ` Aleksandr Mikhalitsyn
2023-06-26 11:49 ` Aleksandr Mikhalitsyn
2023-07-04 1:10 ` Xiubo Li [this message]
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=f885fddd-d511-0e31-cafe-b766144e6207@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).