Sometimes, warnings about ioctls to partition happen often enough that they
form majority of the warnings in the kernel log and users complain. In some
cases warnings are about ioctls such as SG_IO so it's not good to get rid of
the warnings completely as they can ease debugging of userspace problems
when ioctl is refused.
Since I have seen warnings from lots of commands, including some proprietary
userspace applications, I don't think disallowing the ioctls for processes
with CAP_SYS_RAWIO will happen in the near future if ever. So lets just
stop warning for processes with CAP_SYS_RAWIO for which ioctl is allowed.
CC: Paolo Bonzini <[email protected]>
CC: Jens Axboe <[email protected]>
CC: James Bottomley <[email protected]>
CC: [email protected]
Acked-by: Paolo Bonzini <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
---
block/scsi_ioctl.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
Resending rebased on 3.5-rc2 with and Ack from Paolo.
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 260fa80..9a87daa 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -721,11 +721,14 @@ int scsi_verify_blk_ioctl(struct block_device *bd, unsigned int cmd)
break;
}
+ if (capable(CAP_SYS_RAWIO))
+ return 0;
+
/* In particular, rule out all resets and host-specific ioctls. */
printk_ratelimited(KERN_WARNING
"%s: sending ioctl %x to a partition!\n", current->comm, cmd);
- return capable(CAP_SYS_RAWIO) ? 0 : -ENOIOCTLCMD;
+ return -ENOIOCTLCMD;
}
EXPORT_SYMBOL(scsi_verify_blk_ioctl);
--
1.7.1
On 06/15/2012 12:50 PM, Jan Kara wrote:
> Sometimes, warnings about ioctls to partition happen often enough that they
> form majority of the warnings in the kernel log and users complain. In some
> cases warnings are about ioctls such as SG_IO so it's not good to get rid of
> the warnings completely as they can ease debugging of userspace problems
> when ioctl is refused.
>
> Since I have seen warnings from lots of commands, including some proprietary
> userspace applications, I don't think disallowing the ioctls for processes
> with CAP_SYS_RAWIO will happen in the near future if ever. So lets just
> stop warning for processes with CAP_SYS_RAWIO for which ioctl is allowed.
Agree, merged, finally.
--
Jens Axboe
On Fri, 15 Jun 2012 12:50:57 +0200
Jan Kara <[email protected]> wrote:
> Sometimes, warnings about ioctls to partition happen often enough that they
> form majority of the warnings in the kernel log and users complain. In some
> cases warnings are about ioctls such as SG_IO so it's not good to get rid of
> the warnings completely as they can ease debugging of userspace problems
> when ioctl is refused.
>
> Since I have seen warnings from lots of commands, including some proprietary
> userspace applications, I don't think disallowing the ioctls for processes
> with CAP_SYS_RAWIO will happen in the near future if ever. So lets just
> stop warning for processes with CAP_SYS_RAWIO for which ioctl is allowed.
>
> CC: Paolo Bonzini <[email protected]>
> CC: Jens Axboe <[email protected]>
> CC: James Bottomley <[email protected]>
> CC: [email protected]
> Acked-by: Paolo Bonzini <[email protected]>
> Signed-off-by: Jan Kara <[email protected]>
Acked-by: Alan Cox <[email protected]>
On 2012-06-15 12:51 +0200, Jens Axboe wrote:
> On 06/15/2012 12:50 PM, Jan Kara wrote:
> > Sometimes, warnings about ioctls to partition happen often enough that they
> > form majority of the warnings in the kernel log and users complain. In some
> > cases warnings are about ioctls such as SG_IO so it's not good to get rid of
> > the warnings completely as they can ease debugging of userspace problems
> > when ioctl is refused.
> >
> > Since I have seen warnings from lots of commands, including some proprietary
> > userspace applications, I don't think disallowing the ioctls for processes
> > with CAP_SYS_RAWIO will happen in the near future if ever. So lets just
> > stop warning for processes with CAP_SYS_RAWIO for which ioctl is allowed.
>
> Agree, merged, finally.
Hurray!
This should be -stable material as well, as >=3.2.y kernel versions are
affected (I think 3.0.y is OK?).
Thanks,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
> This should be -stable material as well, as >=3.2.y kernel versions
> are affected (I think 3.0.y is OK?).
Not sure, but -ENOIOCTLCMD needed to be changed to -ENOTTY on some
kernel versions (but the conflicts will make this pretty evident).
Paolo
On Fri 15-06-12 09:58:25, Nick Bowler wrote:
> On 2012-06-15 12:51 +0200, Jens Axboe wrote:
> > On 06/15/2012 12:50 PM, Jan Kara wrote:
> > > Sometimes, warnings about ioctls to partition happen often enough that they
> > > form majority of the warnings in the kernel log and users complain. In some
> > > cases warnings are about ioctls such as SG_IO so it's not good to get rid of
> > > the warnings completely as they can ease debugging of userspace problems
> > > when ioctl is refused.
> > >
> > > Since I have seen warnings from lots of commands, including some proprietary
> > > userspace applications, I don't think disallowing the ioctls for processes
> > > with CAP_SYS_RAWIO will happen in the near future if ever. So lets just
> > > stop warning for processes with CAP_SYS_RAWIO for which ioctl is allowed.
> >
> > Agree, merged, finally.
>
> Hurray!
>
> This should be -stable material as well, as >=3.2.y kernel versions are
> affected (I think 3.0.y is OK?).
3.0 also spits those warnings. But I'm not convinced this is really a
-stable material. I don't see anybody loosing sleep over this...
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On 2012-06-15 16:23 +0200, Jan Kara wrote:
> On Fri 15-06-12 09:58:25, Nick Bowler wrote:
> > On 2012-06-15 12:51 +0200, Jens Axboe wrote:
> > > On 06/15/2012 12:50 PM, Jan Kara wrote:
> > > > Sometimes, warnings about ioctls to partition happen often enough that they
> > > > form majority of the warnings in the kernel log and users complain. In some
> > > > cases warnings are about ioctls such as SG_IO so it's not good to get rid of
> > > > the warnings completely as they can ease debugging of userspace problems
> > > > when ioctl is refused.
> > > >
> > > > Since I have seen warnings from lots of commands, including some proprietary
> > > > userspace applications, I don't think disallowing the ioctls for processes
> > > > with CAP_SYS_RAWIO will happen in the near future if ever. So lets just
> > > > stop warning for processes with CAP_SYS_RAWIO for which ioctl is allowed.
> > >
> > > Agree, merged, finally.
> >
> > Hurray!
> >
> > This should be -stable material as well, as >=3.2.y kernel versions are
> > affected (I think 3.0.y is OK?).
> 3.0 also spits those warnings. But I'm not convinced this is really a
> -stable material. I don't see anybody loosing sleep over this...
These messages are quite annoying on my raid boxes (currently running
3.2.y) where mdadm spews a whole pile of these whenever you do anything.
Even with the rate limiting, they make up a substantial proportion of
the total log messages.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)