On Thu, Jun 2, 2016 at 7:09 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > On Tue, May 31, 2016 at 04:07:28PM -0400, Eric Griffith wrote: >> On May 31, 2016 15:44, "Adam Williamson" <adamwill@xxxxxxxxxxxxxxxxx> wrote: >> > >> > On Tue, 2016-05-31 at 15:26 -0400, Eric Griffith wrote: >> > > What if the Anaconda team changed it so the "Make this user an >> > > administrator" checkbox also enabled linger? >> > >> > anaconda team is (rightly) opposed to anything like this, in terms of >> > magic code in anaconda that changes things. All that box does is put >> > the user in the wheel group (and maybe tell PolicyKit they're an admin, >> > I forget if that's a separate thing or not). It does not and will not >> > do anything else. Anything else has to be achieved in terms of saying >> > 'wheel members / PK admins can do X'. >> >> Fair enough, reasonable position. Would this avenue be reasonable / >> acceptable / possible, then? Can logind read and respond to policykit? Such >> as "members of wheel can linger"? I'm not familiar enough with the >> internals of either logind or policykit to know how interconnected they can >> be. > > logind already uses polkit. Current polkit policy installed by systemd > in fact is already more permissive than what you propose: it allows > *any* user to enable lingering for themselves. So enabling it for > wheel-members/other-admin-users wouldn't make much sense. But if the > current policy was ever changed (either upstream or locally), using > this kind of policy would make a lot of sense. Sure, but why do we need so many layers of policy here? We have KillUserProcesses=, KillOnlyUsers=, KillExcludeUsers=, and the polkit configuration, and they all kind-of-sort-of control the same thing. In Fedora 23 and 24, any user can keep processes around after logout by default, and in Rawhide they still can, except that they have to work harder to do it. ISTM there are two things that might be reasonably configured: 1. Is a given user permitted to create processes that persist beyond logout? 2. If a user may create processes that persist beyond logout, *which* processes persist beyond logout? I would argue that (1) is a reasonable thing for an admin to be able to configure, but I think it should be configured in one place, not two. I would argue that (2) has nothing to do with admin-imposed policy and is simply a matter of what the *user* wants and should be done with reasonable APIs. For a user who is permitted to create persistent processes, nohup, tmux, screen, etc should absolutely create persistent processes. gconf, ibus, pulseaudio, etc should not. Presumably, things in non-default scopes should persist [1], as should explicit services that aren't configured to automatically shut down. Anyway, here's an actual idea: could systemd and GNOME arrange for terminal programs (things invoked in gnome-terminal, via ssh, etc) to persist and things that are graphical or dbus to not persist? For example, GNOME could stick everything into a scope that is killed when the GNOME session ends, gnome-terminal could split its children into a different scope, and ssh sessions could have a scope that always lingers (if permitted)? x [1] but not quite as persistently as they do now: https://bugzilla.redhat.com/show_bug.cgi?id=1340508 https://bugzilla.redhat.com/show_bug.cgi?id=1340508 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
