Messages in this thread | | | Date | Mon, 26 Jun 2023 10:12:39 +0800 | Subject | Re: [PATCH v5 00/14] ceph: support idmapped mounts | From | Xiubo Li <> |
| |
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 >>
| |