On Mon, Jun 6, 2016 at 9:56 AM, Benjamin Kreuter <ben.kreuter@xxxxxxxxx> wrote: > On Sat, 2016-06-04 at 19:36 +0200, Roberto Ragusa wrote: >> On 06/02/2016 01:04 PM, Lennart Poettering wrote: >> >> > >> > Well. Let's say you are responsible for the Linux desktops of a >> > large >> > security-senstive company (let's say bank, whatever), and the >> > desktops >> > are installed as fixed workstations, which different employees >> > using >> > them at different times. They log in, they do some "important >> > company >> > stuff", and then they log out again. Now, it's a large company, so >> > it >> > doesn't have the closest control on every single employee, and >> > sometimes employees leave the company. Sometimes even the employees >> > browse to the wrong web sites, catch a browser exploit and suddenly >> > start runing spam bots under their user identity, without even >> > knowing. >> Do you really want to support a disruptive change in default >> behaviour >> with such a specific use case? > > It is a common *enterprise* concern -- which is fine for enterprises > that can afford to pay full-time sysadmins to configure systemd, > policykit, SELinux, etc. The problem here is that there are a large > number of non-enterprise users who are going to have to deal with yet > another unexpected behavior and yet another hard-to-locate > configuration option. > > Yes, hard-to-locate, not because systemd's documentation is lacking but > because it will take time to even realize that systemd is the problem. Even if you suspect systemd, which is reasonable because it legitimately has the authority to manage processes, there's nothing in the log that shows that it is systemd killing the process and why, in a traceable manner, so the user can alter policy if they don't like what's happening. I think the point of the feature is to improve the ratio of deliberate to incidental/unintended behaviors. But the example I've come up with is deliberately initiated and privileged, yet it's killed by this feature on logout. Soo? Is that a bug? -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
