Message-ID: <5084791d6ec7b09c5f3047a376cc8677.squirrel@faumail.uni-erlangen.de>
Date:	Sun, 22 Mar 2015 23:03:03 +0100
From:	helene.gsaenger@...dium.fau.de
To:	helene.gsaenger@...dium.fau.de
Cc:	gregkh@...uxfoundation.org, jslaby@...e.cz, dh.herrmann@...il.com,
	daniel.vetter@...ll.ch, peter@...leysoftware.com, tiwai@...e.de,
	mark.d.rustad@...el.com, joe@...ches.com,
	linux-kernel@...r.kernel.org, linux-kernel@...cs.fau.de,
	simone.weiss@....de, helene.gsaenger@...dium.fau.de
Subject: questions to planned lock-functionality for vts

Hello,


We want to add a functionality to the kernel that allows to lock and unlock
virtual terminals to maybe one day replace X11 screensavers and console
lockers by a more secure kernel mechanism.

It should behave like:
If user A owns e.g. vt2, A is able to lock vt2 and unlock it again.
This is realized by a userspace programm that calls ioctl, which the above
mentioned added cases VT_LOCK and VT_UNLOCK.
Another user(that is not root) wouldn't be allowed to un-/lock vt2.
If anybody wants to change to a looked VT he gets redirected to vt12.
At vt12 a userspace programm (to unlock a VT) would run and ask for
loginname and password, if it is the password from the user that owns the
locked terminal or from root.
The VT gets unlocked and the user gets directed to his terminal.


We try to realize this the following way:

We added the three cases VT_LOCK, VT_UNLOCK and VT_IS_LOCKED to the switch
case in the method vt_ioctl.
VT_LOCK and VT_UNLOCK set and reset the vc_locked flag we have added as
member variable in the struct vc_data after checking the permissions and
VT_IS_LOCKED returns the current value of vc_locked.

When the Kernel switches consoles we want it to check first if the vt we
want to switch to is locked. If it is locked we want to redirect to vt12.
To realize the redirection we figured out two different approaches.


Option 1: realize the redirection in set_console:

Check if the console we want to switch to is locked.
In this case we set nr (the number of te vt we want to switch to) to 11.
Additionally we set the redirected-flag, a member variable we also added
to struct vc_data.

In many cases VT_WAITACTIVE is called after switching vt.
This function waits until the vt switch to the console with the specified
number is completed.
If we switch to vt12 instead of the initially intended vt this function
must be told to wait for a switch to vt12 and not to the intended vt.
So we need to check if the redirected-flag is set.

This approach has a few problems:
	- Besides VT_WAITACTIVE there are more functions that wait for a
	  console switch.
	  To make them work correctly they all must be found and modified.
	  When new functions that wait for a console change are implemented
	  they also must pay attention to this.
	- if there are more callers of set_console and VT_WAITACTIVE race
	  conditions might occur.


Option 2: realize the redirection in complete_change_console:

check if the vt we want to switch to is locked.
In this case we change the value of the struct vc_data *vc, which represents
the vt we want to switch to, to vc_cons[11].d.
But vt_event_post is either way called with the number of the vt we
initially want to switch to.
As a result there is no need for additional checks before waiting for the
vt switch to complete.

This approach seems to be better but we are not sure if calling vt_event_post
with numbers of vts we actually do not switch to is a good idea and has no
side effects in other functions.


None of these options seems to be really good.
So we would like to know if one of this options is better and if anyone knows
a better way to realize the redirection to vt12.


Regards,

Helene Gsaenger and Simone Weiss

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists