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

On Tue, 16.11.10 19:55, Alan Cox (alan@...rguk.ukuu.org.uk) wrote:

> 
> > we always will apply the final result just fine, when stuff stops
> > changing. It's actually a nice feature and no a problem at all, that
> > we only see the most recent state.
> 
> Stuff never stops changing until the machine shuts down, its undefined.
> 
> > Sure, with the ioctl() we've seen many not interesting changes, but we
> > often miss the single one that is important -- the last last one. The
> > thing is that we don't need to sleep here and miss changes.
> 
> So we fix the ioctl interface, it's not exactly hard to do now is it.

Sorry, the WAITEVENT stuff interface you created is unusably broken:

  a) it's a sleeping ioctl which makes it unusable in anything but the
  most trivial applications, because most programs need to respond to
  more than once wakeup event. Of course, you can then introduce threads
  but that's horrible.

  b) It loses events, because events that happen after you woke up and
  before you go back into WAITEVENT are completely lost. And those
  events might actually be relevant, since they might be the most recent events
  that happened. And those tend to be ones that matter.

Kay's interface also drops events, but only historic events that happened
but aren't current anymore. And that's a good thing, because when you
track which VT is in the foreground for presentation, or for permission
management purposes then you care little of who else should have had
access in the past but didn't get it. You are only interested in the most
recent update, which is what Kay's interface gives you. 

Kay's interface is not intended to be useful for logging purposes. It is
useful to track VT changes for service activation, for permission
management.

> > It's a straight-forward and simple text interface that does all we
> > need to track console and vt changes.
> 
> Except that it doesn't address things like the permissions side of
> things.

Well, the suff it provides is purely informational. You cannot actually
influence the TTY in anyway, you can just watch which VT is currently
active.

I don't think that information should be protected more than
necessary. If 

> "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.

I am sorry, but WAITEVENT doesn't work for *any* case. It is completely
broken. Have you actually ever tried to use it yourself? Do it. Write me
a race-free program with it that tracks VT switches and i'd be amazed!

> Fix the one we have.

Well, to fix the existing one, you'd a) have to turn it into something
with a pollable fd, and b) something that doesn't lose current
events. And voila, you'll have created Kay's interface.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ