Re: systemd 230 change - KillUserProcesses defaults to yes

Vít Ondruch <vondruch@xxxxxxxxxx> · Thu, 2 Jun 2016 07:05:49 +0200



    Dne 1.6.2016 v 18:18 Ben Rosser
      napsal(a):

    
          On Wed, Jun 1, 2016 at 10:58 AM,
            Matthias Clasen <mclasen@xxxxxxxxxx> wrote:

            On Wed,
              2016-06-01 at 09:59 -0400, Matthew Miller wrote:

              
              >

              > This paints a very specific premise of what a
              "logout" is, and I'm

              > not

              > sure I agree with it. There are actually many cases
              where I want to

              > use

              > resources on systems I have accounts on without
              specifically being

              > logged in — the login session is just a connection in
              to manage

              > things.

              >

              > Otherwise, we should remove user crontabs, at, and
              similar.  And

              > there

              > are definitely some systems where that policy has a
              place, but I

              > don't

              > see it making sense as Fedora default, either system
              wide or for any

              > of

              > the Editions.

              >

              
              Explicitly marking things to escape the session (nohup,
              crontab,

              starting system services, etc) is very different from just
              leaking any

              and all non-terminating processes out of the session.

              
              I am very much in favor of systemd enforcing that the
              session actually

              ends when I log out, so that I don't accidentally leave
              processes

              running. Leaking session processes have been a perennial
              problem that

              we have been battling forever (gconf, ibus, pulseaudio,
              the list goes

              on...). And they are causing actual problems, from
              preventing re-login

              to subtly breaking the next session to slowing down
              shutdown.

              
              That doesn't mean that you can't have user crontabs. As
              Lennart says,

              using those mechanisms should ideally be a privileged
              operation (with a

              lenient policy on single-user systems).

              
                  Matthias

                
                --

                
            Why should the policy only be lenient on single-user
              systems?
            

            Even if I accept for the moment that letting a user
              keep processes running on a system when they log out
              should be considered "privileged", this is a privilege
              that has more or less always been granted to users by
              default. Why do we suddenly need to change the default?
          
        
    I'd say that the privilege was granted by accident not by design and
    this should change now, since systemd introduces infrastructure to
    fix this. I consider this reasonable, although it apparently breaks
    some forkflows. As long as there is way to change the defaults for
    experienced users, I welcome such change. I dare to say that this is
    good feature for majority of Fedora users although from the
    discussion of experienced users on this list it might seem to break
    the whole world.

    
    Vít

    
            Sure, providing functionality to *remove* that
              privilege from a user as necessary is a nice feature. But
              I would strongly be opposed to the distribution suddenly
              changing the status quo here without good reason.
            

            Ben Rosser
          
        
      --
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx

    
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx