commit be0d5f02c9194fe41c1aad11d7282db117bda938
Author: Kay Sievers <[email protected]>
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 <[email protected]>
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 <[email protected]>
+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 <[email protected]>
+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 = 0;
+
+ acquire_console_sem();
+ for (c = console_drivers; c; c = c->next) {
+ if (!c->device)
+ continue;
+ if (!c->write)
+ continue;
+ if ((c->flags & CON_ENABLED) == 0)
+ continue;
+ cs[i++] = c;
+ if (i >= ARRAY_SIZE(cs))
+ break;
+ }
+ while (i--)
+ count += sprintf(buf + count, "%s%d%c",
+ cs[i]->name, cs[i]->index, i ? ' ':'\n');
+ release_console_sem();
+
+ return count;
+}
+static DEVICE_ATTR(active, S_IRUGO, show_cons_active, NULL);
+
+static struct device *consdev;
+
+void console_sysfs_notify(void)
+{
+ if (consdev)
+ sysfs_notify(&consdev->kobj, NULL, "active");
+}
+
/*
* Ok, now we can initialize the rest of the tty devices and can count
* on memory allocations, interrupts etc..
@@ -3245,15 +3281,18 @@ int __init tty_init(void)
if (cdev_add(&tty_cdev, MKDEV(TTYAUX_MAJOR, 0), 1) ||
register_chrdev_region(MKDEV(TTYAUX_MAJOR, 0), 1, "/dev/tty") < 0)
panic("Couldn't register /dev/tty driver\n");
- device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 0), NULL,
- "tty");
+ device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 0), NULL, "tty");
cdev_init(&console_cdev, &console_fops);
if (cdev_add(&console_cdev, MKDEV(TTYAUX_MAJOR, 1), 1) ||
register_chrdev_region(MKDEV(TTYAUX_MAJOR, 1), 1, "/dev/console") < 0)
panic("Couldn't register /dev/console driver\n");
- device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 1), NULL,
+ consdev = device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 1), NULL,
"console");
+ if (IS_ERR(consdev))
+ consdev = NULL;
+ else
+ device_create_file(consdev, &dev_attr_active);
#ifdef CONFIG_VT
vty_init(&console_fops);
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index a8ec48e..76407ec 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -236,6 +236,14 @@ enum {
};
/*
+ * /sys/class/tty/tty0/
+ *
+ * the attribute 'active' contains the name of the current vc
+ * console and it supports poll() to detect vc switches
+ */
+static struct device *tty0dev;
+
+/*
* Notifier list for console events.
*/
static ATOMIC_NOTIFIER_HEAD(vt_notifier_list);
@@ -688,6 +696,8 @@ void redraw_screen(struct vc_data *vc, int is_switch)
save_screen(old_vc);
set_origin(old_vc);
}
+ if (tty0dev)
+ sysfs_notify(&tty0dev->kobj, NULL, "active");
} else {
hide_cursor(vc);
redraw = 1;
@@ -2967,13 +2977,24 @@ static const struct tty_operations con_ops = {
static struct cdev vc0_cdev;
+static ssize_t show_tty_active(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "tty%d\n", fg_console + 1);
+}
+static DEVICE_ATTR(active, S_IRUGO, show_tty_active, NULL);
+
int __init vty_init(const struct file_operations *console_fops)
{
cdev_init(&vc0_cdev, console_fops);
if (cdev_add(&vc0_cdev, MKDEV(TTY_MAJOR, 0), 1) ||
register_chrdev_region(MKDEV(TTY_MAJOR, 0), 1, "/dev/vc/0") < 0)
panic("Couldn't register /dev/tty0 driver\n");
- device_create(tty_class, NULL, MKDEV(TTY_MAJOR, 0), NULL, "tty0");
+ tty0dev = device_create(tty_class, NULL, MKDEV(TTY_MAJOR, 0), NULL, "tty0");
+ if (IS_ERR(tty0dev))
+ tty0dev = NULL;
+ else
+ device_create_file(tty0dev, &dev_attr_active);
vcs_init();
diff --git a/include/linux/console.h b/include/linux/console.h
index 95cf6f0..0752d92 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -145,7 +145,7 @@ extern int is_console_locked(void);
extern int braille_register_console(struct console *, int index,
char *console_options, char *braille_options);
extern int braille_unregister_console(struct console *);
-
+extern void console_sysfs_notify(void);
extern int console_suspend_enabled;
/* Suspend and resume console messages over PM events */
diff --git a/kernel/printk.c b/kernel/printk.c
index 9a2264f..16f2084 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1357,6 +1357,7 @@ void register_console(struct console *newcon)
spin_unlock_irqrestore(&logbuf_lock, flags);
}
release_console_sem();
+ console_sysfs_notify();
/*
* By unregistering the bootconsoles after we enable the real console
@@ -1415,6 +1416,7 @@ int unregister_console(struct console *console)
console_drivers->flags |= CON_CONSDEV;
release_console_sem();
+ console_sysfs_notify();
return res;
}
EXPORT_SYMBOL(unregister_console);
On Tue, 16 Nov 2010 16:46:40 +0100
Kay Sievers <[email protected]> wrote:
> commit be0d5f02c9194fe41c1aad11d7282db117bda938
> Author: Kay Sievers <[email protected]>
> Date: Tue Nov 9 18:53:59 2010 +0100
>
> tty: add 'active' sysfs attribute to tty0 and console device
This is all somewhat weird.
> Userspace can query the actual virtual console, and the configured
> console devices behind /dev/tt0 and /dev/console.
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
put it in the tty ioctls where it can be properly locked and used.
> +What: /sys/class/tty/tty0/active
> +Date: Nov 2010
> +Contact: Kay Sievers <[email protected]>
> +Description:
> + Shows the currently active virtual console
> + device, like 'tty1'.
> + The file supports poll() to detect virtual
> + console switches.
NAK this, its a nonsense interface
Seriously what use is an interface that tells you "what the console might
have been", this is why we have a proper event tracking interface instead.
> +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 = 0;
> +
> + acquire_console_sem();
> + for (c = console_drivers; c; c = c->next) {
> + if (!c->device)
> + continue;
> + if (!c->write)
> + continue;
> + if ((c->flags & CON_ENABLED) == 0)
> + continue;
> + cs[i++] = c;
> + if (i >= ARRAY_SIZE(cs))
> + break;
> + }
> + while (i--)
> + count += sprintf(buf + count, "%s%d%c",
> + cs[i]->name, cs[i]->index, i ? ' ':'\n');
> + release_console_sem();
> +
> + return count;
> +}
> +static DEVICE_ATTR(active, S_IRUGO, show_cons_active, NULL);
This makes more sense.
> - device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 0), NULL,
> - "tty");
> + device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 0), NULL, "tty");
Please keep unneccessary reformatting patches out of code changes, submit
them separately.
> static ATOMIC_NOTIFIER_HEAD(vt_notifier_list);
> @@ -688,6 +696,8 @@ void redraw_screen(struct vc_data *vc, int is_switch)
> save_screen(old_vc);
> set_origin(old_vc);
> }
> + if (tty0dev)
> + sysfs_notify(&tty0dev->kobj, NULL, "active");
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
etc.
> +static ssize_t show_tty_active(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "tty%d\n", fg_console + 1);
> +}
> +static DEVICE_ATTR(active, S_IRUGO, show_tty_active, NULL);
How do you ensure fg_console returned to user space is right when the
console can change during and after the call ?
On Tue, Nov 16, 2010 at 16:57, Alan Cox <[email protected]> wrote:
> On Tue, 16 Nov 2010 16:46:40 +0100
> Kay Sievers <[email protected]> wrote:
>
>> commit be0d5f02c9194fe41c1aad11d7282db117bda938
>> Author: Kay Sievers <[email protected]>
>> Date: Tue Nov 9 18:53:59 2010 +0100
>>
>> tty: add 'active' sysfs attribute to tty0 and console device
>
> This is all somewhat weird.
>
>> Userspace can query the actual virtual console, and the configured
>> console devices behind /dev/tt0 and /dev/console.
>
> 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
> put it in the tty ioctls where it can be properly locked and used.
>
>> +What: /sys/class/tty/tty0/active
>> +Date: Nov 2010
>> +Contact: Kay Sievers <[email protected]>
>> +Description:
>> + Shows the currently active virtual console
>> + device, like 'tty1'.
>> + The file supports poll() to detect virtual
>> + console switches.
>
> NAK this, its a nonsense interface
>
> Seriously what use is an interface that tells you "what the console might
> have been", this is why we have a proper event tracking interface instead.
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
> > NAK this, its a nonsense interface
> >
> > Seriously what use is an interface that tells you "what the console might
> > have been", this is why we have a proper event tracking interface instead.
>
> 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.
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 ???
On Tue, Nov 16, 2010 at 18:14, Alan Cox <[email protected]> wrote:
>> > NAK this, its a nonsense interface
>> >
>> > Seriously what use is an interface that tells you "what the console might
>> > have been", this is why we have a proper event tracking interface instead.
>>
>> 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.
>
> 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 ???
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
> 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.
> 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.
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
On Tue, Nov 16, 2010 at 20:55, Alan Cox <[email protected]> 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.
Either you don't, or you just don't want to understand what all this
is about. :)
>> 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.
>
>> 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.
>
> NAK again
Specifics please.
> "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.
Kay
> > 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.
> > 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.
> > "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.
On Tue, Nov 16, 2010 at 21:49, Alan Cox <[email protected]> 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
On Tue, 16.11.10 19:55, Alan Cox ([email protected]) 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.
On Tue, 16.11.10 20:49, Alan Cox ([email protected]) wrote:
> /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.
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
informatin I can find out with a simple stat() on the tty caller.
> sysfs also lacks vhangup so you can't fix it right now either.
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.
On Tue, 16 Nov 2010 22:42:50 +0100
Lennart Poettering <[email protected]> wrote:
> On Tue, 16.11.10 20:49, Alan Cox ([email protected]) wrote:
>
> > /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.
>
> Well, I find the informatoin who is logged in much more valuable then
> the information whether I am active or not.
Well thats fine for your machine, what about the rest of us ?
> > 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.
So those are both trivial enough to fix as far as I can see but by the
sound of it neither actually solve what you want to do.
> 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.
No Kay's interface gives you some random reasonably recent answer that
could well be wrong.
> 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.
You wish to do permission management based upon stale unlocked data,
yeah that sounds about the standard of some of the current shipping
desktops.
> 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.
Try that with "keystrokes" for example. its a bogus argument.
> 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!
You have to hold the vt switch locks, but that is unavoidable.
> events. And voila, you'll have created Kay's interface.
Which also doesn't work reliably and you want to use it for permissions
management !
Describe this permission management you are doing please.
Alan
On Tue, 16.11.10 22:51, Alan Cox ([email protected]) wrote:
>
> On Tue, 16 Nov 2010 22:42:50 +0100
> Lennart Poettering <[email protected]> wrote:
>
> > On Tue, 16.11.10 20:49, Alan Cox ([email protected]) wrote:
> >
> > > /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.
> >
> > Well, I find the informatoin who is logged in much more valuable then
> > the information whether I am active or not.
>
> Well thats fine for your machine, what about the rest of us ?
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.
> 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.
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
figure them out doesn't mean they don't exist.
> 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().
Then it needs to start 0600 - security starts by failing safe.
> 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.
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
On Tue, 16.11.10 22:56, Alan Cox ([email protected]) wrote:
> > 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.
>
> So those are both trivial enough to fix as far as I can see but by the
> sound of it neither actually solve what you want to do.
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
block VT switches and the kernel indefinitely. Which is dangerous.
> > 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.
>
> No Kay's interface gives you some random reasonably recent answer that
> could well be wrong.
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
it isn't up-to-date the moment you enter poll() again. Race-free.
> > 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.
>
> You wish to do permission management based upon stale unlocked data,
> yeah that sounds about the standard of some of the current shipping
> desktops.
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
just use inotify on the device nodes, which in fact many already do).
> > 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.
>
> Try that with "keystrokes" for example. its a bogus argument.
Jeez. Kay's interface does not expose keystrokes. Just a simple integer
which tells yu which VT is current.
> > events. And voila, you'll have created Kay's interface.
>
> Which also doesn't work reliably and you want to use it for permissions
> management !
>
> Describe this permission management you are doing please.
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.
On Tue, 16.11.10 23:04, Alan Cox ([email protected]) wrote:
>
> > 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.
>
> Thge current kernel supports you not knowing who is using which
> console,
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.
> 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
> block VT switches and the kernel indefinitely. Which is dangerous.
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
- one for your management daemon, and perhaps one for someone debugging.
> latest info available. And the POLLPRI makes sure that you will notice
> it isn't up-to-date the moment you enter poll() again. Race-free.
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
about whether it is being done right.
> > > 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.
> >
> > Try that with "keystrokes" for example. its a bogus argument.
>
> Jeez. Kay's interface does not expose keystrokes. Just a simple integer
> which tells yu which VT is current.
Stop acting dumb for a moment, I was pointing out the generality of the
argument was daft.
> > Describe this permission management you are doing please.
>
> 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.
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. That's a limit which is
already becoming a bit of an embarrasment with the capabilities of the
current DRI.
I think I'd rather have a proper event kfifo device (which is a tiny bit
of code) and which can in future support multi-console stuff and which
integrates with the existing kernel vt switch locking when the user has
suitable rights and wants to do that.
Now if you got
open /dev/vtmgr
poll
event structure
which behaved with the same behaviour as your magic sysfs hook off a
device file you would I assume be happy even though the data is just as
useless as your current scheme ?
It would however allow reporting of more things, allow us to go
multi-head without the API breaking (providing the messages are
sensibly designed) and support synchronous notification/approval which the
sysfs file won't and it would fix all the VT_WAITEVENT equivalent
functionality for all the potential users.
Not sure I'd want to allow more than one opener to do notify/approval
stuff.
Codewise its pretty trivial - misc device register, alloc a page sized
kfifo on open, free it on close, yank a kfifo entry on read, do poll
properly and stuff the messages posted down each open one.
Serious question - do we even need multiple openers. Your model for this
is a manager app which presumably can provide events to any other bit of
the desktop that cares and in fact probably should be the person doing
that so that it can sequence and control things cleanly ?
(we an always add multiple opener later)
Alan
> 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.
Actually almost nothing in the OS cares about what another user is doing,
and you can have per mount /dev - a la Plan 9.
> 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?
procfs, to users.. not in that kind of environment !
> 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
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
current pseudo-secure bits.
> 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!
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
>>>>> "Lennart" == Lennart Poettering <[email protected]> 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
On Wed, 17 Nov 2010 00:10:24 +0100, Lennart Poettering said:
> 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.
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.
On Wed, Nov 17, 2010 at 23:01, <[email protected]> wrote:
> On Wed, 17 Nov 2010 00:10:24 +0100, Lennart Poettering said:
>
>> 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.
>
> 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.
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
> 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. :)
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
On Wed, Nov 17, 2010 at 11:56:47PM +0000, Alan Cox wrote:
> > 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. :)
>
> 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.
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
On Wed, 17.11.10 17:27, Greg KH ([email protected]) wrote:
> 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?
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.
On Thu, Nov 18, 2010 at 02:48:48AM +0100, Lennart Poettering wrote:
> On Wed, 17.11.10 17:27, Greg KH ([email protected]) wrote:
>
> > 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?
>
> 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.
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
On Wed, 17.11.10 17:53, Greg KH ([email protected]) wrote:
>
> On Thu, Nov 18, 2010 at 02:48:48AM +0100, Lennart Poettering wrote:
> > On Wed, 17.11.10 17:27, Greg KH ([email protected]) wrote:
> >
> > > 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?
> >
> > 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.
>
> I think you mean s/1/3/ here, right?
Yes, of course. Sorry for the confusion.
Lennart
--
Lennart Poettering - Red Hat, Inc.
> - the existing ioctl is broken and no userspace program can use
> it properly, so it might as well be removed.
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
because neither of them cover the needed functionality.
> - Kay's patch is one proposed solution for what userspace is
> wanting to learn about ttys. Werner's is another one.
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
that ?
> 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?
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 "live"
virtual consoles at a time.
If you have a /dev/vtmanager or similar and opening it allocates a kfifo
of a page into which we stuff the events we currently post for waitevent
then the code is trivial and it does what Kay needs as well as being able
to cover the rest of the WAITEVENT interface and future multi-desktop
stuff.
So its trivial to do the job properly, which makes the existing patches
all the wrong thing to do.
Alan
On Wed, Nov 17, 2010 at 05:53:10PM -0800, Greg KH wrote:
> On Thu, Nov 18, 2010 at 02:48:48AM +0100, Lennart Poettering wrote:
> > On Wed, 17.11.10 17:27, Greg KH ([email protected]) wrote:
> >
> > > 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?
> >
> > 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.
>
> 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.
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/
> 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.
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
here.
> 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.
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
On 2010-11-18, Alan Cox <[email protected]> wrote:
>> - the existing ioctl is broken and no userspace program can use
>> it properly, so it might as well be removed.
>
> 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
> because neither of them cover the needed functionality.
>
>> - Kay's patch is one proposed solution for what userspace is
>> wanting to learn about ttys. Werner's is another one.
>
> 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
> that ?
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
we need to know to switch to the new user.
>> 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?
>
> 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
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
so far with the async behavior.
> - 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 "live"
> virtual consoles at a time.
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 'active'
file, if that really will ever happen, which I seriously don't expect.
> If you have a /dev/vtmanager or similar and opening it allocates a kfifo
> of a page into which we stuff the events we currently post for waitevent
> then the code is trivial and it does what Kay needs as well as being able
> to cover the rest of the WAITEVENT interface and future multi-desktop
> stuff.
>
> So its trivial to do the job properly, which makes the existing patches
> all the wrong thing to do.
I'm not against this, it might be what others are looking for. We
could also use that, even when it's 100 times more complicated than
the simple poll()able text interface.
As long as we can have multiple subscribers doing the same thing, and
have a way not to block VT switches, but receive all this
asynchronously.
I just expect a ton of problems if we now start making VT switches
block, which they never did before.
Kay
On 2010-11-18, Dr. Werner Fink <[email protected]> wrote:
> On Wed, Nov 17, 2010 at 05:53:10PM -0800, Greg KH wrote:
>> On Thu, Nov 18, 2010 at 02:48:48AM +0100, Lennart Poettering wrote:
>> > On Wed, 17.11.10 17:27, Greg KH ([email protected]) wrote:
>> >
>> > > 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?
>> >
>> > 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.
>>
>> 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.
>
> 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.
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
On Thu, Nov 18, 2010 at 11:23:35AM +0000, Alan Cox wrote:
> > 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.
>
> 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
> here.
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
waiting in front of (before /dev/ttyS0 or /dev/tty3270 or whatever).
> > 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.
>
> 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.
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
> 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
> waiting in front of (before /dev/ttyS0 or /dev/tty3270 or whatever).
Ok that is a rather nebulous concept for embedded. The answer probably
being that the true console device has no input facility.
> 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
Try the lp printer console if you want a test case
> to detect the primary console device here.
Why not just open /dev/console ?
Alan
> 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
better get a console switch right.
> 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.
Except we've already shown that is false for the more security concious
case, so we need the kernel ability to handle both.
> 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
> we need to know to switch to the new user.
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,
but I do care that the interface in question is general purpose.
> Synchronous interface means we block the VT switch until we have
> handled the event in userspace? We have several in-kernel VT switches
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
synchronous switching.
> during suspend-resume and such. I really don't think this will want to
> wait for userspace to do random crap in /dev? :)
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
but I'd have to check with X hackers on that.
> We also never want single-use interfaces again. It's a pain when we
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
where you might want multiple users, but that is easy to do.
> 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()?
Depending where you do the VT synchronous handling.
> 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
> so far with the async behavior.
Fine so don't choose to use it. Oh wait you already are as you use the X
server.
> > solve the problem properly, and if we are careful about the message
> > formats cover the fact the KMS folks and others want multiple "live"
> > virtual consoles at a time.
>
> 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.
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
surfaces.
> I also see problems with a lot of compat stuff that is based on
> fg_console, and ...
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
several times.
> > If you have a /dev/vtmanager or similar and opening it allocates a kfifo
> > of a page into which we stuff the events we currently post for waitevent
> > then the code is trivial and it does what Kay needs as well as being able
> > to cover the rest of the WAITEVENT interface and future multi-desktop
> > stuff.
> >
> > So its trivial to do the job properly, which makes the existing patches
> > all the wrong thing to do.
>
> I'm not against this, it might be what others are looking for. We
> could also use that, even when it's 100 times more complicated than
> the simple poll()able text interface.
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
noddy too, kfifo even does all the locking needed.
> As long as we can have multiple subscribers doing the same thing, and
> have a way not to block VT switches, but receive all this
> asynchronously.
>
> I just expect a ton of problems if we now start making VT switches
> block, which they never did before.
An API that forces you to block VT switches when you don't want it is as
broken as an API which only supports async.
I don't for one minute intend to propose an API that forces synchronous
on you, or in fact to propose anyone implements multi-way synchronous vt
switch management first time around the implementation.
Alan
On Thu, Nov 18, 2010 at 12:58:22PM +0000, Alan Cox wrote:
> > 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
> > waiting in front of (before /dev/ttyS0 or /dev/tty3270 or whatever).
>
> Ok that is a rather nebulous concept for embedded. The answer probably
> being that the true console device has no input facility.
>
> > 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
>
> Try the lp printer console if you want a test case
>
> > to detect the primary console device here.
>
> Why not just open /dev/console ?
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
> How can I detect the major and minor of the primary console device
> of /dev/console without controlling tty? Even if my old blogd
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
bound).
> 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).
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.
On Thu, Nov 18, 2010 at 02:41:23PM +0000, Alan Cox wrote:
> > How can I detect the major and minor of the primary console device
> > of /dev/console without controlling tty? Even if my old blogd
>
> 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.
ACK ... nevertheless sometime it could be very useful to be able to
debug the user space boot process on e.g. big irons aka mainframes.
> 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
> bound).
Even with this case and IMHO a copy of all system console messages
would be sometimes useful for debugging.
> > 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).
>
> 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.
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
and http://lkml.org/lkml/1998/3/21/57).
> 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.
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/
> 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
So perhaps the vendors using TIOCGDEV could get off their collective
backsides and submit it upstream ?
Alan
On Fri, Nov 19, 2010 at 03:47:05PM +0000, Alan Cox wrote:
> > 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
>
> So perhaps the vendors using TIOCGDEV could get off their collective
> backsides and submit it upstream ?
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/
On Fri, Nov 19, 2010 at 03:47:05PM +0000, Alan Cox wrote:
> > 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
>
> So perhaps the vendors using TIOCGDEV could get off their collective
> backsides and submit it upstream ?
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
On Fri, Nov 19, 2010 at 10:02:58AM -0800, Greg KH wrote:
> On Fri, Nov 19, 2010 at 03:47:05PM +0000, Alan Cox wrote:
> > > 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
> >
> > So perhaps the vendors using TIOCGDEV could get off their collective
> > backsides and submit it upstream ?
>
> 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...
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/
> 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).
I think the market won the argument on this one - so please yes - submit
it.
On Sat, Nov 20, 2010 at 12:40:20PM +0000, Alan Cox wrote:
> > 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).
>
> I think the market won the argument on this one - so please yes - submit
> it.
Just to be sure, do you have noticed my mail with the
ID <[email protected]> which had
attached the the patch?
Werner
--
System V style init programs - http://savannah.nongnu.org/projects/sysvinit/
Just have dug out this one:
On Fri, Nov 19, 2010 at 06:07:36PM +0100, Werner Fink wrote:
> On Fri, Nov 19, 2010 at 03:47:05PM +0000, Alan Cox wrote:
> > > 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
> >
> > So perhaps the vendors using TIOCGDEV could get off their collective
> > backsides and submit it upstream ?
>
> 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/
On Wed, Dec 01, 2010 at 11:37:49AM -0600, Milton Miller wrote:
> On Wed, 01 Dec 2010 about 12:32:22 -0000, Werner Fink wrote:
> >
> > Just have dug out this one:
>
> One question and two minor nits.
>
> >
> > On Fri, Nov 19, 2010 at 06:07:36PM +0100, Werner Fink wrote:
> > > On Fri, Nov 19, 2010 at 03:47:05PM +0000, Alan Cox wrote:
> > > > > 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
> > > >
> > > > So perhaps the vendors using TIOCGDEV could get off their collective
> > > > backsides and submit it upstream ?
> > >
> > > 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
> >
> >
> > >From 3ed084a05b7d28d65f6cc42c96696c7cb49c84a1 Mon Sep 17 00:00:00 2001
> > In-Reply-To: <[email protected]>
> > References: <[email protected]>
> > From: Werner Fink <[email protected]>
> > Date: Fri, 19 Nov 2010 17:54:44 +0100
> > Subject: [PATCH] Add tty ioctl to figure device node of the system console.
> >
>
> Please put a changelog here as per "15) The canonical patch format"
> in Documentation/SubmittingPatches.
>
> >
> > Signed-off-by: Werner Fink <[email protected]>
> >
> > diff --git a/arch/alpha/include/asm/ioctls.h b/arch/alpha/include/asm/ioctls.h
> > index 59617c3..034b6cf 100644
> > --- a/arch/alpha/include/asm/ioctls.h
> > +++ b/arch/alpha/include/asm/ioctls.h
> > @@ -92,6 +92,7 @@
> > #define TIOCGSID 0x5429 /* Return the session ID of FD */
> > #define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of pty-mux device) */
> > #define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
> > +#define TIOCGDEV _IOR('T',0x32, unsigned int) /* Get primary device node of /dev/console */
> > #define TIOCSIG _IOW('T',0x36, int) /* Generate signal on Pty slave */
> >
> > #define TIOCSERCONFIG 0x5453
> > diff --git a/arch/parisc/include/asm/ioctls.h b/arch/parisc/include/asm/ioctls.h
> > index 4e06144..0a10575 100644
> > --- a/arch/parisc/include/asm/ioctls.h
> > +++ b/arch/parisc/include/asm/ioctls.h
> > @@ -52,6 +52,7 @@
> > #define TCSETSF2 _IOW('T',0x2D, struct termios2)
> > #define TIOCGPTN _IOR('T',0x30, unsigned int) /* Get Pty Number (of pty-mux device) */
> > #define TIOCSPTLCK _IOW('T',0x31, int) /* Lock/unlock Pty */
> > +#define TIOCGDEV _IOW('T',0x32, int) /* Get primary device node of /dev/console */
>
> All of the other architetures add this as _IOR but here in parisc
> it is _IOW. Was this intentional or a typo?
Thansk for spotting.
Werner
--
System V style init programs - http://savannah.nongnu.org/projects/sysvinit/