From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752496AbbCWKiU (ORCPT ); Mon, 23 Mar 2015 06:38:20 -0400 Received: from mx-rz-3.rrze.uni-erlangen.de ([131.188.11.22]:34651 "EHLO mx-rz-3.rrze.uni-erlangen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752159AbbCWKiR (ORCPT ); Mon, 23 Mar 2015 06:38:17 -0400 X-Greylist: delayed 529 seconds by postgrey-1.27 at vger.kernel.org; Mon, 23 Mar 2015 06:38:17 EDT X-RRZE-Submit-IP: 131.188.11.53 Message-ID: <1407ab9cdf5fc07ef39080926b3963bb.squirrel@faumail.uni-erlangen.de> In-Reply-To: <20150322222337.GA28785@kroah.com> References: <5084791d6ec7b09c5f3047a376cc8677.squirrel@faumail.uni-erlangen.de> <20150322222337.GA28785@kroah.com> Date: Mon, 23 Mar 2015 11:29:25 +0100 Subject: Re: questions to planned lock-functionality for vts From: simone.weiss@fau.de To: "Greg KH" Cc: helene.gsaenger@studium.fau.de, jslaby@suse.cz, dh.herrmann@gmail.com, daniel.vetter@ffwll.ch, peter@hurleysoftware.com, tiwai@suse.de, mark.d.rustad@intel.com, joe@perches.com, linux-kernel@vger.kernel.org, linux-kernel@i4.cs.fau.de, simone.weiss@fau.de, helene.gsaenger@studium.fau.de User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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