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] [day] [month] [year] [list]
Message-ID: <20120615084644.GA3479@quack.suse.cz>
Date:	Fri, 15 Jun 2012 10:46:44 +0200
From:	Jan Kara <jack@...e.cz>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	Jan Kara <jack@...e.cz>, Jens Axboe <axboe@...nel.dk>,
	LKML <linux-kernel@...r.kernel.org>,
	James Bottomley <JBottomley@...allels.com>,
	linux-scsi@...r.kernel.org
Subject: Re: [PATCH] scsi: Silence unnecessary warnings about ioctl to
 partition

On Fri 15-06-12 10:14:12, Paolo Bonzini wrote:
> Il 02/05/2012 12:10, Jan Kara ha scritto:
> > 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 <pbonzini@...hat.com>
> > CC: Jens Axboe <axboe@...nel.dk>
> > CC: James Bottomley <JBottomley@...allels.com>
> > CC: linux-scsi@...r.kernel.org
> > Signed-off-by: Jan Kara <jack@...e.cz>
> > ---
> >  block/scsi_ioctl.c |    5 ++++-
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> > 
> > 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);
> >  
> > 
> 
> Ping?
  Good that you bring this up :). I've asked the customer about whether
they can find out the particular SG_IO ioctl Veritas issues but never heard
back. So will we merge my patch? I remember you gave it reluctant ack once
;).

									Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ