On Sun, Jun 5, 2016 at 2:20 PM, Paul Wouters <paul@xxxxxxxxx> wrote: > On Fri, 3 Jun 2016, Lennart Poettering wrote: > >>> You are redefining the meaning of (a graphical) logout. It simply >>> means another user can use the mouse, keyboard and screen of this >>> device. It makes no statement on whether the machines resources are >>> shared or not. >> >> >> Actually, with logind, current kernel, current X11 and/or wayland >> there's a very clear statement on sharing devices: logind will ensure >> that only the fg session can access the various evdev and DRM devices, >> and will suspend access for all sessions not currently in the >> fg. Similar, ACLs for a couple of other device nodes are patched >> depending on the fg session (but only for DRM and evdev the ongoing >> connection of bg users is suspended, as there's no concept of a >> generic revoke() in the Linux kernel, but only DRM and evdev-specific >> mechanisms). Locking this down properly, so that background sessions >> or even non-console logins don't get access to your devices has been >> something various folks from various communities have been working >> on for a while. >> >> So yeah, sessions (as defined by logind) are a security concept >> already, and they will make sure that only the right users get access >> to the devices at the right times. > > > That's great. It has however, absolutely nothing to do with backgrounded > processes, and their interpretation of good vs evil by systemd. > > No one is saying when a graphical session ends, you cannot reclaim the > devices required for the next graphical session to start. > > No one is saying you cannot protect physical devices from graphical or > network logins. > > What it is offered now is garbage collection of the global process list, > and people are stating systemd does not have the required to knowledge to > successfully perform that task - and therefore should not try. > > Paul It can do it successfully. It can't do it safely. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
