On Thu, Jun 15, 2023 at 2:29 PM Xiubo Li <xiubli@xxxxxxxxxx> 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 users to set UID/GID-based MDS auth caps from ceph > side. And users should know what has happened. ok, we want to restrict setting of UID/GID-based permissions if there is an idmapped mount on the client. IMHO, idmapping mounts is truly a client-side feature and server modification looks a bit strange to me. > > Once users want to support the idmap mounts they should know that the > MDS auth caps won't work anymore. They will work, but permission rule configuration should include non-mapped UID/GID-s. As I mentioned here [1] it's already the case even without mount idmappings. It would be great to discuss this thing as a concept and synchronize our understanding of this before going into modification of a server side. [1] https://lore.kernel.org/lkml/CAEivzxcBBJV6DOGzy5S7=TUjrXZfVaGaJX5z7WFzYq1w4MdtiA@xxxxxxxxxxxxxx/ Kind regards, Alex > > Thanks > > - Xiubo >
