From: Paolo Bonzini <pbonzini@redhat.com>
To: Ric Wheeler <ricwheeler@gmail.com>
Cc: axboe@kernel.dk, Mike Snitzer <snitzer@redhat.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [Ping^3] Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO
Date: Thu, 06 Sep 2012 08:31:33 +0200 [thread overview]
Message-ID: <50484345.8040508@redhat.com> (raw)
In-Reply-To: <5047B38D.9000607@gmail.com>
Il 05/09/2012 22:18, Ric Wheeler ha scritto:
>>
>
> Hi Paolo,
>
> Both of these commands are destructive. WRITE_SAME (if done without the
> discard bits set) can also take a very long time to be destructive and
> tie up the storage.
FORMAT_UNIT has the same characteristics and yet it is allowed (btw, I
don't think WRITE SAME slowness is limited to the case where a real
write is requested; discarding can be just as slow).
Also, the two new commands are anyway restricted to programs that have
write access to the disk. If you have read-only access, you won't be
able to issue any destructive command (there is one exception, START
STOP UNIT is allowed even with read-only capability and is somewhat
destructive).
Honestly, the only reason why these two commands weren't included, is
that the current whitelist is heavily tailored towards CD/DVD burning.
> I think that restricting them to CAP_SYS_RAWIO seems reasonable - better
> to vet and give the appropriate apps the needed capability than to
> widely open up the safety check?
CAP_SYS_RAWIO is so wide in its scope, that anything that requires it is
insecure.
Paolo
next prev parent reply other threads:[~2012-09-06 6:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-20 16:30 [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO Paolo Bonzini
2012-08-01 15:53 ` Paolo Bonzini
2012-08-28 11:04 ` Paolo Bonzini
2012-09-05 14:41 ` [Ping^3] " Paolo Bonzini
2012-09-05 20:18 ` Ric Wheeler
2012-09-06 6:31 ` Paolo Bonzini [this message]
2012-09-06 11:31 ` Ric Wheeler
2012-09-06 11:49 ` Paolo Bonzini
2012-09-06 12:08 ` Ric Wheeler
2012-09-06 12:36 ` Paolo Bonzini
2012-09-06 14:20 ` Lukáš Czerner
2012-09-11 16:59 ` Tejun Heo
2012-09-11 17:56 ` Paolo Bonzini
2012-09-11 18:29 ` Tejun Heo
2012-09-11 18:54 ` Paolo Bonzini
2012-09-11 19:13 ` Tejun Heo
2012-09-11 19:24 ` Paolo Bonzini
2012-09-11 20:01 ` Tejun Heo
2012-09-11 21:50 ` Paolo Bonzini
2012-09-11 22:02 ` Tejun Heo
2012-09-11 22:10 ` Paolo Bonzini
2012-09-11 22:13 ` Tejun Heo
2012-09-12 8:05 ` James Bottomley
2012-09-12 8:18 ` Paolo Bonzini
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=50484345.8040508@redhat.com \
--to=pbonzini@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ricwheeler@gmail.com \
--cc=snitzer@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.