linux-kernel - Re: [PATCH v5 00/14] ceph: support idmapped mounts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0a42c5d0-0479-e60e-ac84-be3b915c62d9@redhat.com>
Date:   Tue, 4 Jul 2023 09:08:46 +0800
From:   Xiubo Li <xiubli@...hat.com>
To:     Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
Cc:     Gregory Farnum <gfarnum@...hat.com>,
        Christian Brauner <brauner@...nel.org>, stgraber@...ntu.com,
        linux-fsdevel@...r.kernel.org, Ilya Dryomov <idryomov@...il.com>,
        Jeff Layton <jlayton@...nel.org>, ceph-devel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 00/14] ceph: support idmapped mounts

Sorry, not sure, why my last reply wasn't sent out.

Do it again.


On 6/26/23 19:23, Aleksandr Mikhalitsyn wrote:
> On Mon, Jun 26, 2023 at 4:12 AM Xiubo Li<xiubli@...hat.com>  wrote:
>> On 6/24/23 15:11, Aleksandr Mikhalitsyn wrote:
>>> On Sat, Jun 24, 2023 at 3:37 AM Xiubo Li<xiubli@...hat.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 am afraid there is no.

But just after the following ceph PR gets merged it will be easy to do this:

https://github.com/ceph/ceph/pull/48027

This is still under testing.

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

Maybe no need much, it should be simple IMO. But I am not 100% sure.

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

BTW, could you explain it more ? How could this resolve the issue we are 
discussing here ?

Thanks

- Xiubo


>
> Kind regards,
> Alex
>
>> Thanks
>>
>> - Xiubo
>>
>>
>>
>>
>>
>>> Thanks,
>>> Alex
>>>
>>>> Thanks
>>>>
>>>> - Xiubo
>>>>