From: Paolo Bonzini <pbonzini@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Willy Tarreau <w@1wt.eu>,
linux-kernel@vger.kernel.org, security@kernel.org,
pmatouse@redhat.com, agk@redhat.com, jbottomley@parallels.com,
mchristi@redhat.com, msnitzer@redhat.com
Subject: Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices
Date: Fri, 23 Dec 2011 15:15:00 +0100 [thread overview]
Message-ID: <4EF48CE4.3000104@redhat.com> (raw)
In-Reply-To: <CA+55aFxnOwkquH8tirqJnM_KTcavAejY8drL11jy2S+2PXmZuw@mail.gmail.com>
On 12/23/2011 10:22 AM, Linus Torvalds wrote:
> On Thu, Dec 22, 2011 at 10:26 PM, Willy Tarreau<w@1wt.eu> wrote:
>>
>> Call me dumb, but why would someone use "eject" on a non-physically
>> ejectable device such as a memory stick ?
>
> Perhaps because that's the operation that works everywhere and is the
> simplest one?
But does it actually do anything? For me, "eject /dev/sdf1" does
nothing beyond unmounting the disk. Yes, it sends a CDROMEJECT ioctl
which becomes a start/stop unit SCSI command, but it has no effect on
the USB stick I tried.
I tried it on a card reader, and indeed it started reporting "no medium
found" after ejecting.
And actually there it fixes a potential data corruption. Because yes,
most USB sticks and cards have one partition. But if you had two,
"eject /dev/sdf1" would unmount one partition and CDROMEJECT the whole
card. Which means the other partition is left unclean. (Invoked with
"eject /dev/sdb", eject at least tries to go through the partitions and
unmounts all of them. Not bulletproof, but almost there).
So "eject /dev/sdb1" on USB sticks is just an unmount. On card readers
it will indeed be affected by the patch. But the actual eject operation
that it does after unmounting ought to fail. It hasn't so far? Just
another instance of the bug I'm fixing.
> Just look at the icon on your desktop - it probably has "Eject" above
> the silly "Safely remove drive" when you right-click it. It has for
> me.
Assuming you're using GNOME3, for USB sticks the "Eject" button unmounts
the volume, but it leaves the /dev/ files in place. "Safely remove
drive" unmounts the volume and also does what udisks calls "detach". It
sends a start/stop unit SCSI command (same as CDROMEJECT and the eject
command) and then unplugs the device via sysfs. To be precise, it also
sends a cache flush, just in case the disk reported itself as
writethrough but wasn't, so it is actually safer than eject.
But udisks never sends SCSI commands to partition devices, because
udisks knows the distinction between disk and partition. Even on an
unpatched kernel, "udisks --detach /dev/sdf1" fails with "Detach failed:
Device is not a drive". In general, I looked at the source code for
this throughout the GNOME stack (both GNOME2 and GNOME3), and everywhere
they distinguish between "drive" and "volume" objects. Eject maps to a
method on the volume's eject method, while "safely remove drive" maps to
the drive's stop method.
So, no, nothing I tried to do on USB sticks from a recent desktop
environment will break with the patch.
Before udisks, HAL had "unmount" and "eject". With or without the
patch, on USB sticks they act the same. They unmount the volume and
leave /dev/ files in place.
> So yes, I claim that "eject" is actually the *natural* thing to do
> before you physically remove the medium, because it works across
> different media.
If you talk about ejecting the disk, yeah, "safely remove drive" is just
paranoia. But if you talk about ejecting a partition from the
command-line, then no, not at all.
Paolo
next prev parent reply other threads:[~2011-12-23 14:54 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-22 18:02 [PATCH 0/3] possible privilege escalation via SG_IO ioctl (CVE-2011-4127) Paolo Bonzini
2011-12-22 18:02 ` [PATCH 1/3] block: add and use scsi_blk_cmd_ioctl Paolo Bonzini
2011-12-22 18:02 ` [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices Paolo Bonzini
2011-12-22 18:37 ` Linus Torvalds
2011-12-22 19:11 ` Willy Tarreau
2011-12-22 19:18 ` Paolo Bonzini
2011-12-22 19:44 ` Linus Torvalds
2011-12-22 20:23 ` Paolo Bonzini
2011-12-22 20:52 ` Linus Torvalds
2011-12-22 22:08 ` Paolo Bonzini
2011-12-22 22:25 ` Linus Torvalds
2011-12-22 23:48 ` Alasdair G Kergon
2011-12-23 0:07 ` Linus Torvalds
2011-12-23 6:26 ` Willy Tarreau
2011-12-23 9:22 ` Linus Torvalds
2011-12-23 9:45 ` Willy Tarreau
2011-12-23 14:15 ` Paolo Bonzini [this message]
2011-12-23 22:46 ` Linus Torvalds
2012-01-05 13:18 ` Paolo Bonzini
2012-01-05 16:16 ` Linus Torvalds
2012-01-05 16:40 ` Paolo Bonzini
2012-01-05 17:04 ` Linus Torvalds
2012-01-05 17:26 ` Paolo Bonzini
2012-01-05 23:49 ` Linus Torvalds
2011-12-26 1:41 ` Daniel Barkalow
2011-12-23 0:17 ` H. Peter Anvin
2011-12-22 18:02 ` [PATCH 3/3] dm: do not forward ioctls from logical volumes to the underlying device 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=4EF48CE4.3000104@redhat.com \
--to=pbonzini@redhat.com \
--cc=agk@redhat.com \
--cc=jbottomley@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchristi@redhat.com \
--cc=msnitzer@redhat.com \
--cc=pmatouse@redhat.com \
--cc=security@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
/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;
as well as URLs for NNTP newsgroup(s).