Re: questions to planned lock-functionality for vts

[simone.weiss@fau.de]

> Wait, what's wrong with the existing functionality?

Userspace programms for screensavers can potentially be bypassed
- if my scrennsaver dies, for example by segfault, my screen is unlocked
- Redirection is only possible in Kernel, because a vt switch can only
  be prevented there
Also it would make the implementation of a Secure-Acess-Key possible
(could also redirect to VT12)

>> 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.
>
> Why would you want to put all of that into the kernel?

We don't want to put all of that in the kernel, the above describes only
the interaction with a userspace programm.
For the kernel it would only mean that if a vt is locked
it wouldn't allow to switch to this vt and instead switch to VT12.

Regards,
Simone Weiss