Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: mN1om72qfw/G6tZ1wRO/vCBJiycSAL68GYIk7N+HNnBdq4D0EbrK1pnWNPl7NmcFpmwDnQoa+H
 VvmO8N2IcFzLtORoC9aJEnavZHK/b3kZTbm2CbE5ZwlTmE1TEYhlMVBleAl/qD2KZeQesJp54J
 CuvHOUu6Laj4WVWHawGRKRy5782rdyUDA+73KlgNN43NdTIlthxnEaaj6nk7ef84GFELSBkHLd
 NQ1G+QM2lZLQDHh5FILlsvDUEJRVNc5VqbFBWE3XynOgE7UljIlK5UBlB5BltGguRX4fKIXcBj
 PMk=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     "dsterba@suse.cz" <dsterba@suse.cz>
CC:     Niklas Cassel <Niklas.Cassel@wdc.com>,
        Jens Axboe <axboe@kernel.dk>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] blk-zoned: allow BLKREPORTZONE without CAP_SYS_ADMIN
Thread-Topic: [PATCH 2/2] blk-zoned: allow BLKREPORTZONE without CAP_SYS_ADMIN
Thread-Index: AQHXViSI8g5t53fJ2UqQanQJze0fFQ==
Date:   Thu, 3 Jun 2021 11:20:33 +0000
Message-ID: <DM6PR04MB708127C72BDC03B446997DACE73C9@DM6PR04MB7081.namprd04.prod.outlook.com>
References: <20210531135444.122018-1-Niklas.Cassel@wdc.com>
 <20210531135444.122018-3-Niklas.Cassel@wdc.com>
 <20210603095117.GU31483@twin.jikos.cz>
 <DM6PR04MB7081B69E31BB7ADDF02E2D9BE73C9@DM6PR04MB7081.namprd04.prod.outlook.com>
 <20210603100436.GV31483@twin.jikos.cz>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a9735adb-1e02-41e8-e3a4-08d926819a77
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2021 11:20:33.1879
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6/upN7Q7N6IAATa/XJeZsj6z/ahLhEX1qxhY3jExMS81VJzsq/RBcwJZo0WRWj1aL1nP9qBZENb4rx97hnvwFg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR04MB0812
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2021/06/03 19:07, David Sterba wrote:=0A=
> On Thu, Jun 03, 2021 at 10:00:08AM +0000, Damien Le Moal wrote:=0A=
>> On 2021/06/03 18:54, David Sterba wrote:=0A=
>>> On Mon, May 31, 2021 at 01:54:53PM +0000, Niklas Cassel wrote:=0A=
>>>> From: Niklas Cassel <niklas.cassel@wdc.com>=0A=
>>>>=0A=
>>>> Performing a BLKREPORTZONE operation should be allowed under the same=
=0A=
>>>> permissions as read(). (read() does not require CAP_SYS_ADMIN).=0A=
>>>>=0A=
>>>> Remove the CAP_SYS_ADMIN requirement, and instead check that the fd wa=
s=0A=
>>>> successfully opened with FMODE_READ. This way BLKREPORTZONE will match=
=0A=
>>>> the access control requirement of read().=0A=
>>>=0A=
>>> Does this mean that a process that does not have read nor write access=
=0A=
>>> to the device itself (blocks) is capable of reading the zone=0A=
>>> information? Eg. some monitoring tool.=0A=
>>=0A=
>> With this change, to do a report zones, the process will only need to ha=
ve read=0A=
>> access to the device. And if it has read access, it also means that it c=
an read=0A=
>> the zones content.=0A=
> =0A=
> Ok, so this is a bit restricting. The zone information is like block=0A=
> device metadata, comparing it to a file that has permissionx 0600 I can=
=0A=
> see the all the stat info (name, tiemstamps) but can't read the data.=0A=
> =0A=
> But as the ioctl work, it needs a file descriptor and there's probably=0A=
> no way to separate the permissions to read blocks and just the metadata.=
=0A=
> For a monitoring/reporting tool this would be useful. Eg. for btrfs it=0A=
> could be part of filesystem status overview regarding full or near-full=
=0A=
> zones and emitting an early warning or poking some service to start the=
=0A=
> reclaim.=0A=
=0A=
You lost me... the change is less restrictive than before because the proce=
ss=0A=
does not need SYS_CAP_ADMIN anymore. The block device file open is untouche=
d, no=0A=
change. So whatever process could open it before, will still be able to do =
so as=0A=
is. More processes will be able to do report zones with the change. That is=
 all=0A=
really that changes, so I do not see what potentially breaks, nor how this =
may=0A=
prevent writing some monitoring tool. Whoever can open the block device fil=
e has=0A=
FMODE_READ rights, no ? Am I missing something here ?=0A=
=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=