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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/