linux-kernel - Re: How to fix CDROM/DVD eject mess?

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 02 Feb 2015 15:02:23 -0500
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	Kay Sievers <kay@...y.org>
CC:	Takashi Iwai <tiwai@...e.de>, Jens Axboe <axboe@...nel.dk>,
	Oliver Neukum <oneukum@...e.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: How to fix CDROM/DVD eject mess?

On 2015-02-02 14:34, Maciej W. Rozycki wrote:
> On Mon, 2 Feb 2015, Kay Sievers wrote:
>
>>> I thought that fixing the udev behavior would solve the problem.  But
>>> it turned out that I was too naive.  A bigger problem is that all
>>> user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
>>> see this as if the disk is *ready* to be ejected.  KDE, for example,
>>> dismisses the DVD icon when it receives this event even if it's still
>>> mounted.
>>
>> It is not really about being "ready to eject", if the user presses the
>> button, the user does not want to wait for anything else than actually
>> ejecting the media as fast as possible. It is the same as ripping out
>> a USB cable. It needs to work, no matter if things are mounted or
>> busy.
>
>   All the technical details aside, this is a bold statement -- how do you
> know what the user actually wants?
>
>   I for one want to see the medium locked if in use, just as it has been
> since 1990s.  If I wanted to do an emergency eject (the equivalent of
> ripping out a USB cable), then I would use a paperclip in the manual eject
> hole.  So you've got a counterexample to your assertion now.  All people
> are not the same.
>
>   All I want to say here is there seems to be a policy hidden somewhere
> here where it should not.  It's up to the user to decide what suits him or
> her.  We just need to give them the right tools.
>
>> It is just a hardware button event which should not be masked out for
>> rather weird reasons.
>
>   Precisely, and I should have a way to control it.  If I used a GUI, I
> might want the event to pop up a window with the list of current users
> (accessing processes) of the device, perhaps asking if to terminate them.
> Or flip a relay to make my kettle boil water.

I agree, there should be some option to control this, although 
personally, I would prefer two options, one for when it's read-only (in 
which case I would prefer the current behavior), and one for when it's 
read-write (in which case, I would prefer that the door-lock be engaged).

Also, udev's current response isn't all that great either, when it get's 
the event, it should do a lazy unmount of the device.  Windows and OS X 
automatically unmount filesystems from ejected media, so it is expected 
behavior for many users (and I keep meaning to open a bug against udev 
because of this, but keep forgetting).

The fact that it stays mounted can cause all kinds of confusing issues 
as well if the user inserts a different disc; I've seen cases (recently 
in fact) where a new disc was inserted and due to caching, it showed 
dentries from the old disc, but with the files full of gibberish, and it 
refused to unmount the (now invalid) filesystem without using umount -f 
(which shouldn't be needed for a read-only FS, period).

Download attachment "smime.p7s" of type "application/pkcs7-signature" (2455 bytes)