linux-kernel - Re: [REGRESSION] cdrom drive doesn't detect removal

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]

Message-ID: <AANLkTim31g84J6eeuh_6MiEw0w8zOi5sOWrL_WnoaueP@mail.gmail.com>
Date:	Thu, 23 Sep 2010 11:21:08 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Maxim Levitsky <maximlevitsky@...il.com>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>
Subject: Re: [REGRESSION] cdrom drive doesn't detect removal

On Thu, Sep 23, 2010 at 10:47, Tejun Heo <tj@...nel.org> wrote:

> Yeah, what I'm curious about is why hal behaves differently with
> claiming block patch.  Exclusive open still fails with EBUSY with or
> without the patch, right?  So, why does hal behave differently?

We don't support unlocked cd doors. Currently eject/umount of optical
media has to be initiated by the user.

HAL checked if the device was mounted, and if it was, it dropped the
O_EXCL. This was to support polling of the eject-button state, which
worked on a few drives. That's no longer cecked with udisks, it does
O_EXCL only for optical media.

>> Look if it fails. sure the device is open, but if doesn't fail, nothing
>> prevents a bit less honest clients (that don't use exclusive open) to
>> open the device. How exclusive such an open is then?

>> So I mean exclusive open should really block _all_ following opens of
>> the device, exclusive or not.
>
> That will probably break a lot of stuff.

That would surely need a new flag like O_REALLYEXCL. :)

> I'm currently working on in-kernel media presence polling to handle
> the open and polling command sequence issues.  That said, it's not
> entirely clear how the mount case should be handled.  If a media is
> mounted, the device is exclusively open and media presence polling
> shouldn't be inserting commands in the middle but then how can it
> detect the media has been ejected by the user?  Kay, can you please
> enlighten me on how it's supposed to work?

Non-optical devices should not be a problem, and can be always polled,
as it seems. We do this without O_EXCL since forever.

For optical drives I would never ever bypass O_EXCL, like udisks is
doing it. There are far too many problems with burning, which never
got really solved.

Force-removed media (not recommended unlocked doors) might not be
detected until the filesystem is cleaned-up/umounted, but that's
probably the better compromise than fiddling with the broken drives
during burning sessions.

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