linux-kernel - Re: tty: add 'active' sysfs attribute to tty0 and console device

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: <AANLkTik3fdR4zzKq29THQjpW5sNoqFEQsq9vevF6diUi@mail.gmail.com>
Date:	Tue, 16 Nov 2010 22:29:11 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>,
	Lennart Poettering <lennart@...ttering.net>,
	Werner Fink <werner@...e.de>, Jiri Slaby <jslaby@...e.cz>
Subject: Re: tty: add 'active' sysfs attribute to tty0 and console device

On Tue, Nov 16, 2010 at 21:49, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> > Stuff never stops changing until the machine shuts down, its undefined.
>>
>> Either you don't, or you just don't want to understand what all this
>> is about. :)
>
> At what point do you think the current tty stops changing ? The only
> cases I can think of are shutdown, and when your own processes locks vt
> changes.

Hmm, what do you mean? It's not the tty IO. It's only the VT switch,
and this changes only when someone actually does the switch, like
pressing Alt-F1,F2,...

>> > Except that it doesn't address things like the permissions side of things.
>> >
>> > NAK again
>>
>> Specifics please.
>
> /dev/tty* and sysfs nodes don't track permissions, owner with each other,
> so you are providing interfaces that either expose information they
> shouldn't (which screen is valuable info in some environments), or don't
> expose info they should.
>
> sysfs also lacks vhangup so you can't fix it right now either.

You think exposing the currently active VC is security relevant? We
don't expose anything from the VC itself. We have this information all
over the place in userspace. What exactly you think is the problem
here?

>> > "We have an interface that doesn't quite work for our case and we think
>> > that is a bug" is not the reasoning behind writing a new random one with
>> > a totally disconnected permission model that doesn't work either.
>> >
>> > Fix the one we have.
>>
>> So how do you think you'll fix it? I better don't get into your
>> ioctl() business.
>
> Start by explaining why the current interface doesn't work for you, but
> in detail.

The sleeping ioctl() requires a dedicated thread in a service. Now we
wake up and all the stuff that happens now is lost, so we have to
check with another ioctl(), between this ioctl() and going to sleep
again is a window we don't cover, we just go to sleep, even when
something has happened. Poll() solves that by queuing the notification
until it's retrieved.

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/