linux-kernel - Re: questions to planned lock-functionality for vts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANq1E4TOV-jOrAti3KPaBnSfEEJXW96--Vj1A6_S=BUVxZ77qg@mail.gmail.com>
Date:	Mon, 23 Mar 2015 14:26:02 +0100
From:	David Herrmann <dh.herrmann@...il.com>
To:	simone.weiss@....de
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	helene.gsaenger@...dium.fau.de, Jiri Slaby <jslaby@...e.cz>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Peter Hurley <peter@...leysoftware.com>,
	Takashi Iwai <tiwai@...e.de>, mark.d.rustad@...el.com,
	Joe Perches <joe@...ches.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-kernel@...cs.fau.de
Subject: Re: questions to planned lock-functionality for vts

Hi

On Mon, Mar 23, 2015 at 2:02 PM,  <simone.weiss@....de> wrote:
> hello
>
>> By moving these calls into the kernel, you don't make them necessarily
>> fail-safe. This can all be implemented in user-space. By switching to
>> a dedicated VT (say, VT12) and running VT_SETMODE+VT_PROCESS, you lock
>> the machine. You can now implement your screensaver. If you run a
>> spawner-process, you're even safe if your screensaver crashes.
>
> Yes but this would lock the whole machine. Our plan is to make it posible
> to lock a specific set of VTs - owned by the user who wants to lock.
>
> e.g if user A locked all his VTs user B would still be able to switch to
> his VTs.

Correct. But if you want to support locking individual sessions (or
VTs), why not look at what is done with upcoming Wayland compositors,
which implement this in the compositor itself? That is, the session
tracks whether it's locked and shows a lock-screen if so. This can be
done on text-VTs the same as on graphical ones.

I mean, why does the kernel need to know VT state which is inherently
defined the application running on it?

Putting this in the kernel is the easier way out, given the historical
setup of gettys on VTs. But I wonder why it's supposed to be the
better way?

Thanks
David
--
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/