public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Marcus Meissner <meissner@suse.de>
Cc: JBottomley@parallels.com, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: PATCH: scsi: make scsi reset permissions more relaxed (RFC)
Date: Fri, 30 Aug 2013 14:18:04 +0200	[thread overview]
Message-ID: <52208D7C.8000009@suse.de> (raw)
In-Reply-To: <20130830120450.GB31120@suse.de>

On 08/30/2013 02:04 PM, Marcus Meissner wrote:
> Hi folks,
> 
> cdrecord wants to whack the CD drive with a SCSI RESET ...
> 
> So far SCSI RESET can be done at 4 levels (target, device, bus, host)
> and all 4 are checked for CAP_SYS_ADMIN / CAP_SYS_RAWIO.
> 
> 
> As the cdrecord author wants special permissions for cdrecord, readcd ,
> cdda2wav to allow it to send SCSI RESET commands I was wondering if
> relaxing the permission is a potential idea?
> 
> This would allow SCSI reset on target/device if a local user
> gets regular access to a SCSI device (via udev acls etc.)
> 
Hmm. Device and target reset are typically implemented at the
transport level (SCSI itself doesn't have any commands for this).
So it should be possible to inject them via bsg, and as such should
have the same restrictions as bsg has.
Assuming that sg and bsg follow the same rules the patch should be okay.

> 
> (I know that the actual reset code will fall back into the chain
>  target -> device -> bus -> host resetting if one fails.)
> 
Actually, it doesn't. sg_reset_provider() will just call the
individual function.

If the function fails _and_ there are commands send to the device
then the error handling will kick in, but it won't be triggered
directly.
Not sure if that makes a difference, though.

> Signed-off-by: Marcus Meissner <meissner@suse.de>
> 
Acked-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

  reply	other threads:[~2013-08-30 12:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-30 12:04 PATCH: scsi: make scsi reset permissions more relaxed (RFC) Marcus Meissner
2013-08-30 12:18 ` Hannes Reinecke [this message]
2013-08-30 12:47 ` Douglas Gilbert
2013-08-30 16:18   ` Jeremy Linton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52208D7C.8000009@suse.de \
    --to=hare@suse.de \
    --cc=JBottomley@parallels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=meissner@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox