lkml.org 
[lkml]   [2023]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v5 00/14] ceph: support idmapped mounts
From

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
>>

\
 
 \ /
  Last update: 2023-06-26 04:14    [W:0.188 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site