[Patch] scsi_ioctl: support persistent reserve commands for non-root user.

[Patch] scsi_ioctl: support persistent reserve commands for non-root user.

[jiang.biao2]

scsi_ioctl: support persistent reserve commands through ioctl for
non-root user.

Scsi persistent reserve commands need to be used for non-root user in
many scenarios.
EPERM error will be returned by sg_io() when PERSISTENT_RESERVE_OUT
or PERSISTENT_RESERVE_IN command is sent through ioctl() for
non-root user.
Add PERSISTENT_RESERVE_OUT and PERSISTENT_RESERVE_IN into
blk_default_cmd_filter in blk_set_cmd_filter_defaults() to support 
persistent reserve commands for non-root user.

Signed-off-by: Jiang Biao <jiang.biao2@zte.com.cn>
Signed-off-by: Li Ping <li.ping288@zte.com.cn>
Reviewed-by: Liu Jianjun <liu.jianjun3@zte.com.cn>

diff -urpN block/scsi_ioctl.c block_new/scsi_ioctl.c
--- block/scsi_ioctl.c  2015-08-01 17:07:47.000000000 +0800
+++ block_new/scsi_ioctl.c      2015-08-01 17:09:56.000000000 +0800
@@ -202,6 +202,9 @@ static void blk_set_cmd_filter_defaults(
        __set_bit(GPCMD_LOAD_UNLOAD, filter->write_ok);
        __set_bit(GPCMD_SET_STREAMING, filter->write_ok);
        __set_bit(GPCMD_SET_READ_AHEAD, filter->write_ok);
+       /* Persistent reserve command*/
+       __set_bit(PERSISTENT_RESERVE_IN, filter->read_ok);
+       __set_bit(PERSISTENT_RESERVE_OUT, filter->write_ok);
 }

 int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm)

Re: [Patch] scsi_ioctl: support persistent reserve commands for non-root user.

[James Bottomley]

On Tue, 2015-08-04 at 09:11 +0800, jiang.biao2@zte.com.cn wrote:
> scsi_ioctl: support persistent reserve commands through ioctl for
> non-root user.
> 
> Scsi persistent reserve commands need to be used for non-root user in
> many scenarios.
> EPERM error will be returned by sg_io() when PERSISTENT_RESERVE_OUT
> or PERSISTENT_RESERVE_IN command is sent through ioctl() for
> non-root user.
> Add PERSISTENT_RESERVE_OUT and PERSISTENT_RESERVE_IN into
> blk_default_cmd_filter in blk_set_cmd_filter_defaults() to support 
> persistent reserve commands for non-root user.

I'm very dubious about this: a PR third party reservation can deny
access to the local device ... effectively allowing any local user to
cause I/O errors on all devices by issuing a bogus third party
reservation.  What's the reason for allowing non-root use in the first
place?

James

Re: [Patch] scsi_ioctl: support persistent reserve commands for non-root user.

[jiang.biao2]

James Bottomley <James.Bottomley@HansenPartnership.com> wrote on 
2015/08/04 09:32:17:
> On Tue, 2015-08-04 at 09:11 +0800, jiang.biao2@zte.com.cn wrote:
> > scsi_ioctl: support persistent reserve commands through ioctl for
> > non-root user.
> > 
> > Scsi persistent reserve commands need to be used for non-root user in
> > many scenarios.
> > EPERM error will be returned by sg_io() when PERSISTENT_RESERVE_OUT
> > or PERSISTENT_RESERVE_IN command is sent through ioctl() for
> > non-root user.
> > Add PERSISTENT_RESERVE_OUT and PERSISTENT_RESERVE_IN into
> > blk_default_cmd_filter in blk_set_cmd_filter_defaults() to support 
> > persistent reserve commands for non-root user.
> 
> I'm very dubious about this: a PR third party reservation can deny
> access to the local device ... effectively allowing any local user to
> cause I/O errors on all devices by issuing a bogus third party
> reservation.  What's the reason for allowing non-root use in the first
> place?
> 

Hi, Jams. 
Our scenario is using persistent reservation in KVM guest cluster 
when passing through the disk to the guests. The cluster 
software(MSCS, for instance) need to use PR to synchronize the 
cocurrent access to the shared disk. Because the KVM guest is 
running in qemu context, it could not be root.

As to your concerns, should the the bogus reservation and illegal 
access be limited by the other measures, for example, the mode of 
the dev file? Similarly, the *Basic writing commands(WRITE_*)* are 
also dangerous for non-root, but they must be used be by non-root 
user, so they are controlled by file mode and other security 
measures, and not limited it the first place.

Thanks a lot.