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, 2 Feb 2015 19:34:38 +0000 (GMT)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	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 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.

 FWIW,

  Maciej
--
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/