commit be0d5f02c9194fe41c1aad11d7282db117bda938
Author: Kay Sievers <kay.sievers@vrfy.org>
Date:   Tue Nov 9 18:53:59 2010 +0100

    tty: add 'active' sysfs attribute to tty0 and console device
    
    Userspace can query the actual virtual console, and the configured
    console devices behind /dev/tt0 and /dev/console.
    
    The last entry in the list of devices is the active device, analog
    to the console= kernel command line option.
    
    The attribute supports poll(), which is raised when the virtual
    console is changed or /dev/console is reconfigured.
    
    Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>

diff --git a/Documentation/ABI/testing/sysfs-tty b/Documentation/ABI/testing/sysfs-tty
new file mode 100644
index 0000000..b138b66
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-tty
@@ -0,0 +1,19 @@
+What:		/sys/class/tty/console/active
+Date:		Nov 2010
+Contact:	Kay Sievers <kay.sievers@vrfy.org>
+Description:
+		 Shows the list of currently configured
+		 console devices, like 'tty1 ttyS0'.
+		 The last entry in the file is the active
+		 device connected to /dev/console.
+		 The file supports poll() to detect virtual
+		 console switches.
+
+What:		/sys/class/tty/tty0/active
+Date:		Nov 2010
+Contact:	Kay Sievers <kay.sievers@vrfy.org>
+Description:
+		 Shows the currently active virtual console
+		 device, like 'tty1'.
+		 The file supports poll() to detect virtual
+		 console switches.
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index c05c5af..be5ab4a 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3232,9 +3232,45 @@ static int __init tty_class_init(void)
 postcore_initcall(tty_class_init);
 
 /* 3/2004 jmc: why do these devices exist? */
-
 static struct cdev tty_cdev, console_cdev;
 
+static ssize_t show_cons_active(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct console *cs[16];
+	int i = 0;
+	struct console *c;
+	ssize_t count = ...
[ message continues ]

On Tue, 16 Nov 2010 16:46:40 +0100


All the other vt interface code is in the vt driver, the ioctls for it
are in the vt driver and a query about what is the active vt only has
meaning within that context as you need to post a waitevent first to
track changes during the query. So if you need a VT_GETACTIVE interface

NAK this, its a nonsense interface

Seriously what use is an interface that tells you "what the console might


Please keep unneccessary reformatting patches out of code changes, submit

What is the locking on tty0dev at this point ? Wrong place anyway - we
have vt change notifiers that do this properly and can track other
changes like console sizes, add and remove. See the VT_WAITACTIVE stuff

How do you ensure fg_console returned to user space is right when the
console can change during and after the call ?

--

[ message continues ]

You mean the VT_WAITEVENT? Sleeping ioctls() can't be used. The time
between the check for the current, and you go to sleep in the ioctl()
for teh next is a window which isn't covered with such interface.

And 'might have been' does not matter, it's fine. We just need change
notification, and can query the actual vt again.

Kay
--

[ message continues ]

The only thing you need to add is VT_GETACTIVE, which is fine providing
you know how to use it, but in both cases it is basically useless because
by the time you've asked the question the answer is undefined. You can
only use an interface of this type if you lock against VT changes, which
is how the X interface works if you look at it.

So what are you going to do with the return value from an interface which
provide "what was the console, perhaps, at some point you asked but could
even have been deleted, assigned to a different user, hot unplugged or
moved to another framebuffer device by the time I answer"

What is it for ???

--

[ message continues ]

It's for tracking changes. Every async event interface might carry
values which are not true anytime after the event. But, unlike with
the ioctl(), that does not matter for us, because changes are always
signaled with poll() and there is no window between a check and the
next wait-for-the-next-event which can't be covered.

Sleeping ioctl()s like VT_EVENT can't be used to track the current VT
because they might go to sleep() even when stuff has changed since the
last check. We actually need to revert its use from ConsoleKit because
it can't be fixed properly, and actually causes problems for people.

It does not matter if things change at high frequency underneath us,
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.

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.

It's a straight-forward and simple text interface that does all we
need to track console and vt changes.

Kay
--

[ message continues ]

Except that it doesn't address things like the permissions side of things.

NAK again

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

Alan
--

[ message continues ]

Either you don't, or you just don't want to understand what all this


So how do you think you'll fix it? I better don't get into your
ioctl() business.

Kay
--

[ message continues ]

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

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


Start by explaining why the current interface doesn't work for you, but
in detail.
--

[ message continues ]

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

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

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

[ message continues ]

Well, I find the informatoin who is logged in much more valuable then
the information whether I am active or not. And the who is logged in

Which is a feature, no a bug. It would be kinda messy if the service
which manages device access based on whose session is active would
always be forcibly stopped from doing so if somebody calls vhangup().

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--

[ message continues ]

On Tue, 16 Nov 2010 22:42:50 +0100

Well thats fine for your machine, what about the rest of us ?
--

[ message continues ]

I think most people (except maybe you) find it more security relevant if
it is leaked who's logged in and on which tty then it is to know whether
that's the active session or not.

And as long as we have no problem with letting everybody know who is
logged in, and on which tty we shouldn't waste brain cells on discussing
whether it is a problem if they also find out whether that login is
currently active or not.

Also, sysfs supports perms just fine. If you don't want people to see
it, then just chmod 600 the sysfs file, and nobody can see it
anymore. That's a trivial thing to do. It's a lot more difficult to hide
who's logged in, since the user who is logged in takes possession of the
tty file which everybody can see and stat(), even if not open().

This is really a pointless discussion. Security is not an issue
here. Which tty is currently active is completely boring information,
and the least we should think about. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--

[ message continues ]

Thge current kernel supports you not knowing who is using which console,
furthermore there are environments where this is both used and the
current console is *very* important information.

The fact you lack the knowledge of such environments or even the wit to


Wrong. That's the kind of sloppy attitude that causes bugs, poor code and
security holes. It's the kind of arrogant "it only gets used like I say
it does so screw the rest of you" attitude that the certain desktops are
wrecked by.

So we *are* going to discuss the security, we are going to discuss the
permissions and we are going to discuss the permissions management model
you are trying to implement because when we've done that there is a good
chance of finding a model that a) works b) is secure and c) solves your
specific problem case.

Alan
--

[ message continues ]

How would that work? Not giving a user ownership of the tty device? That
would break like about every second program. It's too late for this.

And anyway unless the kernel is patched you can even see who is running
which process on the system. And now you become all nervous about
telling people which tty is currently in the fg? Seriously?

Security is a fog granade here. It's a non-issue.

Also, afaics the current ioctl() interface you love so much works on any
tty and gives you that information anyway, right? Some tty fd should be
accessible by about every process and VT_GETSTATE on that and you have
the same information -- and no further perm checking is done at all! So
isn't Kay's approach much nicer, where you can actually protect this
oh-so-precious information in a much tighter fashion thatn with normal
ioctls!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--

[ message continues ]

Actually almost nothing in the OS cares about what another user is doing,


I'm not particularly attached to the ioctl interface, and I'm not
disagreeing with you that it needs redoing to actually be useful for what
you want and for a lot of other cases. The question is what the resulting
interface should look like so its useful for more than just your specific

You need to have access to a console fd, which in that case is normally
fine, but it is a weakness and one reason I know about that is because it
has been complained about !

And as you say setting it to 0600 fixes that aspect. I've no problem
with that either as SELinux rules can manage it effectively.

Alan
--

[ message continues ]

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

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

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

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

[ message continues ]

So those are both trivial enough to fix as far as I can see but by the

No Kay's interface gives you some random reasonably recent answer that

You wish to do permission management based upon stale unlocked data,
yeah that sounds about the standard of some of the current shipping



Which also doesn't work reliably and you want to use it for permissions
management !

Describe this permission management you are doing please.

Alan
--

[ message continues ]

Trivial enough to fix? No it isn't. We tried to come up with a sane fix
for the current ioctl() iface, but it's not feasible. a) is unfixable
anyway without some kind of additional fd, since the tty fd is not
really something you want to overload with new POLLxxx events. For b)
you either need a per-consumer queue, so that no events are lost. That
is cumbersome, and would add a massive amount of code to the kernel. Or
you need some kind of atomic extenstion a la "wait only if this
information is still current". Which would work for our use case but
still eat events that happen between the WAITEVENT calls. Or you would
have to do this synchronous, which would basically allow userspace to

The POLLPRI bit is set until the moment you read the current VT
value. Then it is atomically reset at the same time as your read(). At
that time the VT info is up-to-date and the newest one. If it then
changes again, the POLLPRI bit is set again, and the next time you call
poll() you will be notified about that and wakeup right away. With other
words: the moment you read the VT info from the kernel it is always the
latest info available. And the POLLPRI makes sure that you will notice

What matters is that we fix the perms before we inform clients about the
VT switches. It does not matter that change the perms before the kernel
officially went through with the VT switch. Or in other words:
delivery of notification about VT switches can be done asynchronously
between the kernel and the perm manager. But from the perm manager to
the services we need synchronous notification. (Or, alternatively, they

Jeez. Kay's interface does not expose keystrokes. Just a simple integer

When two users A and B are logged in, on tty1 resp. tty2, then as long
as tty1 is active user A should get access to the sound card, usb key,
.... As soon as we switch to tty2 user B should.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--

[ message continues ]

Any kernel interface with a queue will lose events or block, its a
mathematical limit. A bounded length per consumer queue is really trivial
to implement thanks to the kfifo code and its easy enough to have an
overflow event to say "you didn't keep up, sort out your context"

Agreed entirely it needs a separate fd.

I wouldn't have expected there to have been many live queues in a system

That's not the usual definition of race free. It merely means that you
can ask 'was the data I used obsolete', not race-free which is 'is the
data I have valid'. Trouble is by then you've used it. That's my concern

Stop acting dumb for a moment, I was pointing out the generality of the

So firstly you need to implement revoke.

That aside you still have the problem that you will lag in your
permission changes so if user B is quick they can get access to things
belonging to user A. No big deal for sound output but a bit bad for
reformatting his USB key.

We get what

	poll
	what tty
	tty1 - oh thats fred
	switch to tty2 bill

	set all the rights for fred
	Oh bugger while we've been remounting file systems (can take 30
	seconds easily) bill has been a bad boy (or just got fed up of
	the wrong music)

So yes it'll always run after the correct answer (which waitactive wont)
but I don't see how you can build a real permission model on it. I do see
how you can use it to get the right sound playing and the like which
waitactive can't do right. Furthermore you aren't going to be able to do
real permissions with it when you get revoke because at the point your
switching is actually a real permission boundary you need to be able to
have the daemon also lock the vt to stop changes. We do support that kind
of locking of vt switching, and in the past fifteen years it hasn't been
a big problem. In particular it does the relevant unlocking and the like
if the owner dies.

Your interface is also going to go castors up once we allow multiple
active vts at once belonging to multiple users. ...
[ message continues ]

>>>>> "Lennart" == Lennart Poettering <mzxreary@0pointer.de> writes:

Lennart> When two users A and B are logged in, on tty1 resp. tty2,
Lennart> then as long as tty1 is active user A should get access to
Lennart> the sound card, usb key, .... As soon as we switch to tty2
Lennart> user B should.

Hmm, it's an interesting idea, and I run into this myself when my son
logs into my desktop as himself and wants to hear sound.

But I wonder how do you handle the case where there are multiple seats
(KVM+S) on one system?  Do you have a mapping table?  

John
--

[ message continues ]

So I change to tty1, plug in my 8G USB memory stick, and I have access to it.
I start copying something big to it, and change to tty2 to do something else
while the long copy happens...

... and my copy craps out because tty1 lost access to the USB.

Brilliant.

[ message continues ]

Brilliant conclusion. If you have mounted it, you own it. But you can
not make your inactive session mount another new one. It's like this
since ages. Hint: try stuff before hitting reply too fast. :)

Kay
--

[ message continues ]

Except during the window when screen switching, or of course you could
just ssh in remotely and gdb or similar a process with it as controlling
tty running on your console and issue a vt switch back, then mount it.
Ironically the move from a root owned X server has made that much simpler
to automate, although it was always possible.

Given you can often guess from the idle data if the victim has gone away
from the box it's not ideal. Even better any mess will appear on my
display and get hidden when I flip it back.

The only way to stop that is to make use of the display locking facility
which takes us back where we began in saying that a usable interface is
going to need to lock the display.

At that point the current console owner has to choose to allow the
console to be switched which can be limited effectively to physical
console access and done synchronously. In turn that means to abuse it I
already have physical access to the other users key so could just as
easily steal it and the software security is therefore sufficient.

Alan
--

[ message continues ]

Ok, we are way-off-topic here from the original points.

Which are:
	- the existing ioctl is broken and no userspace program can use
	  it properly, so it might as well be removed.
	- Kay's patch is one proposed solution for what userspace is
	  wanting to learn about ttys.  Werner's is another one.

So, what to do?

I can do any one, or multiple things from the following options:

	- disable the existing ioctl to return an error so that no new
	  userspace program starts to use it thinking it is valid
	- accept Werner's patch for those who like proc files
	- accept Kay's patch

Any suggestions?

thanks,

greg k-h
--

[ message continues ]

Maybe this is not so surprising, but I definitely want item #3 from the
list. 

I am against #2, since #1 is a much nicer solution, and having both
would be needlessly redundant.

And #1 would be a good idea.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--

[ message continues ]

I think you mean s/1/3/ here, right?

And yes, having both will be redundant, and Werner seems to not be
responding anymore as to why he feels his patch is somehow still needed
given that Kay's patch accomplishes the same thing from what I can tell.

thanks,

greg k-h
--

[ message continues ]

Yes, of course. Sorry for the confusion.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--

[ message continues ]

I'm still reading and I'm wondering about this discussion.  The only
thing I'd like to be able is to detect all ttys used for the system
console even if not a VT (not having a VT but several other consoles
is the most pressing case e.g. on s390 or zSeries) and this without
forcing (and maybe stealing) the controlling tty on the system console
to be able to detect the primary tty/console.

The primary tty marked with CON_CONSDEV and normally the first in
console_drivers.  This can be done with Kay's patch as well as with
my approach.  And both approaches do have the advantage to become
the full list of consoles which will help me to extend e.g. sulogin ...

The only advantage of my approache in comparision to Kay's one is that
the remaining console flags become visible for normal user space.
This was an idea of Randy Dunlap otherwise my patch would provide
the same information as the patch of Kay.

Maybe Kay could extend his patch in that way that the flags and the
facilities (having device, read, write, and unblank) are also shown
in the new file /sys/class/tty/console/active ... but maybe Randy
could says a few words for what this is usable.

     Werner

-- 
System V style init programs - http://savannah.nongnu.org/projects/sysvinit/
--

[ message continues ]

What do you mean by console in this context

The console in printk context and the "console" in "active vt window" are
unrelated concepts with the same name, so its a bit confusing to follow

The system console does not even need to be a tty device, and on many
embedded devices is not (it may for example by a RAM buffer not wiped
over reboots or it may be jtag or MIPI trace ports.

"tty0" is *currently* a shorthand for "the VT the keyboard/display are
showing". That's a shorthand that in itself will make no sense in future.

Alan
--

[ message continues ]

Example: running a boot script on /dev/console and after fsck
sulogin has to called to be able to asked the system admin.
Now the question is which console device the system admin is

I'm aware of.  For using tty devices of the system console it requires
to have e.g. with my patch:

  bash> cat /proc/tty/consoles 
  tty0                 -WU (ECp)       4:7

the `W' flag for write and the major:minor pair, beside this the `U'
flag indicates the tty can do an unblank operation, the `-' shows that
there is no read operation (never seen such a console tty).  On an other
system here I see:

  bash> cat /proc/tty/consoles
  ttyS0                -W- (ECp)       4:64
  tty0                 -WU (Ep)        4:1

which I'm using in user space with

    dev_t dev = 0;
    FILE * fc;

    if ((fc = fopen("/proc/tty/consoles", "r"))) {
        char fbuf[16];
        int maj, min;
        while ((fscanf(fc, "%*s %*s (%[^)]) %d:%d", &fbuf[0], &maj, &min) == 3)) {
            if (!strchr(fbuf, 'E'))
                continue;
            if (strchr(fbuf, 'C')) {
                dev = makedev(maj, min);
                break;
            }
        }
        fclose(fc);
    }

to detect the primary console device here.


       Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr
--

[ message continues ]

Ok that is a rather nebulous concept for embedded. The answer probably


Why not just open /dev/console ?

Alan

--

[ message continues ]

How can I detect the major and minor of the primary console device
of /dev/console without controlling tty?  Even if my old blogd
and the bootlogd(8) of SysInitV using TIOCCONS are outdated by SystemD
the question before doing the TIOCCONS is which is the primary console
device to e.g. create the device node in initrd or for bootlogd(8)
to write a copy of the console messages back to the original
primary console (and the other console devices).

   Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr
--

[ message continues ]

In the general case you can't - because a console may not have a tty.
Quite a few don't. For the cases where one has a device I can't see a
clean way to do it as an fstat on the console device will give you the
console major/mninor and some code depends upon that.

The iniability to get it is clearly a flaw and you need the sysfs link or
a sysfs list of consoles (again remembering many of them won't have a tty

For init it is /dev/console as opened at boot time and passed to the
initial user init task but with no nice way to work back to a device node.

Incidentally the primary console (as in printk) can be accessed as a tty
via the ttyprintk driver which got added recently because embedded people
wanted to use the printk interface as a (write only) tty console as well.




--

[ message continues ]

ACK ... nevertheless sometime it could be very useful to be able to

Even with this case and IMHO a copy of all system console messages

Currently the bootlogd(8) or blogd(8) parse the kernels command line
and if available do an ioctl TIOCGDEV (not supported by the upstream
kernel), then create a pty/tty pair, do an ioctl TIOCCONS to forward
the system console to the created tty, now both daemons can parse
all console messages to write out logs and write all copies to the
former devices node(s) (compare with http://lkml.org/lkml/2000/12/15/160

I've seen that in the changelog of the kernel ... maybe this would
a good replacment for the /dev/kmsg redirect of stdout/stderr in initrd.


     Werner

-- 
System V style init programs - http://savannah.nongnu.org/projects/sysvinit/
--

[ message continues ]

So perhaps the vendors using TIOCGDEV could get off their collective
backsides and submit it upstream ?

Alan
--

[ message continues ]

That I've tried 10 years before. If you think it's worth to retry
you may have a look on the attachment only for a short review

     Werner

-- 
System V style init programs - http://savannah.nongnu.org/projects/sysvinit/
[ message continues ]

Heh, that's what started this whole thing :)

I objected to TIOCGDEV going in as it seemed that only suse needed it
for their boot sequence, and no other distro did which implied that it
really wasn't necessary.

I'm still not convinced it is needed, and the many thousands of booting
systems out there without it seem to confirm it...

thanks,

greg k-h
--

[ message continues ]

Uhmm ... just to say it: I've been asked by Fedorea people and also
by Debian people why I had not submitted this patch and I've told
them that I had it done long time ago ;)

It seems to me that there is some demand but most user space
monitoring applications uses workarounds (AFAICR plymouth
uses hard coded VT for boot and shutdown).


  Werner

-- 
System V style init programs - http://savannah.nongnu.org/projects/sysvinit/
--

[ message continues ]

I think the market won the argument on this one - so please yes - submit
it.
--

[ message continues ]

Just to be sure, do you have noticed my mail with the
ID <20101119170736.GA4177@boole.suse.de> which had
attached the the patch?

   Werner

-- 
System V style init programs - http://savannah.nongnu.org/projects/sysvinit/
--

[ message continues ]

I'm pretty sure such flags, if they are meant to be exported to
userspace (which I have no good idea about) belong to the individual
devices, and not in the 'active' file.

We surely can do that, if that fits into the general picture. You
could poll(console/active) for changes, get the list of devices, and
look at them individually. poll() will tell you when you dynamically
need to adapt your service.

Kay
--

[ message continues ]

You can use it happily for various things providing you hold the vt
switch lock. It's not a very good API and wants something doing about it.
However we can't deprecate it using either of the proposed patches

Kay's patch is useless. As we've demonstrated by as you call it "going
off topic" it can't actually provide a credible security model. Its
providing a variable without holding the locks that make the value
meaningful. Thats as basic an error I can think of.

We wouldn't accept kernel code which did

	mutex_lock(&foo->lock)
	temp = foo->only_valid_under_lock;
	mutex_unlock(&foo->lock);
	return temp;	/* ma invalid by now */

especially when it was going to be used for permission management. We'd
call it a bug. So why are we proposing to add an API that does exactly

None of the above. In fact the current situation is better than either of
the patches because it's equally broken and involves no more broken APIs !

Doing it right means:
- deprecating the existing ioctl (because it's a dumb interface and Kay
  is right about that)
- adding a proper event device which is pollable and returns the same
  events (and more) using a small kfifo queue. Trivial to code and will
  not add another API we'll need to deprecate again the moment anyone
  wants to use it.
- support synchronous switching by that interface or verify the existing
  vt locking interfaces will do the job in conjunction with it.

Kay's approach doesn't solve three things

- You can't use the data to implement proper secure desktop switching
- It doesn't support moving to multiple active vts at a time
- You can't deprecate the wait event interface unless you replace all the
  features of it that people use (eg resize events)

So we will be back here again doing the same thing deprecating Kay's
interface if we go that way. Having an event device actually lets us
solve the problem properly, and if we are careful about the message
formats cover the fact the KMS folks and others want multiple ...
[ message continues ]

All this is just no real issue for us. This is not about security in
the sense of untrusted users being able to do something they couldn't
do already, it's about passing the currently active user _some_
additional rights.

And if that user goes inactive there will always be a window where
this user keeps some rights it had while active. There is always some
kind of overlap, and even if we had revoke() we probably couldn't it
for many reasons. Soft hand-over is the expected behavior. But the
poll() will still show us that *something* has changed, and it's all

Synchronous interface means we block the VT switch until we have
handled the event in userspace? We have several in-kernel VT switches
during suspend-resume and such. I really don't think this will want to
wait for userspace to do random crap in /dev? :)

We also never want single-use interfaces again. It's a pain when we
need to switch to some new way of doing things,a nd need to run two
services during the transition period. It is also always handy for
debugging. We will not use any single-user-subscribe interface. It's
an absolute requirement in the Linux eco-system not to block kernel
interfaces with a running service, otherwise we end up with the
/proc/acpi/* nightmare.

So if we have multiple subscribers, we need for all subscribers to
finish userspace handling and let all other block in the VT switch
ioctl()?

That all sounds nice to have for some tasks, sure no doubt, but it
sounds pretty complicated/fragile for what we need to do. We are fine

As far as I know, the future is VT-like stuff in Wayland-like things
using a pty, and not legacy kernel-based VTs at all. They even think
to leave all kernel VT stuff behind, because there are too many
assumptions about, and they don't fit into the modern world of
internationalization key/font-handling anyway.

I also see problems with a lot of compat stuff that is based on
fg_console, and ...

And last, we could just have more than a single name in the ...
[ message continues ]

> All this is just no real issue for us. This is not about security in

The kernel isn't "for us", it has to cleanly solve the general purpose
cases for all the usage cases. That varies from home type desktops where
security isn't so important to secure installations where you damned well

Except we've already shown that is false for the more security concious

Of course you could fix it, you make the desktop change in that case
synchronous. Most of what is needed is already there.

Now I don't care whether your particularly desktop bothers to or not,

It means you have the option to do so. Clearly at boot time it would get
a bit silly to do that. So for your use case you'd not ask for

Of course I'd point out every X based VT switch is currently synchronous.
I don't believe X has any hooks for doing stuff mid switch via helpers

There are lots of interfaces where single opener makes total sense so
that's not a good generalisation. I would agree the vt interface is one


Fine so don't choose to use it. Oh wait you already are as you use the X

No - the problem you have is that the kernel VT layer is two things

1.	It's a VT100 emulator
2.	It's a display surface and set of input bindings.

Plug two keyboards into a PC and right now we fail to support two
keyboard/two mouse/two screens even though all the hardware can do it. In
that situation the VT interface is in many ways a legacy element but it
ought to work, and the blanking and screen switching create a nasty mess
if you try and hack around it and the notion it keeps of the display

That's relatively easy to transition we add a

struct all_the_crap_i_need_to_round_up {}

and reference off it, then allow multiple instances. Been there done that

I don't think it is looking at the code. If I thought otherwise I'd be
less jumping up and down about it. We already have an abstraction which
is an event (ie message) in the code and thanks to kfifo the rest is

An API that forces you to block VT switches when you ...
[ message continues ]