:: Re: [DNG] resolved
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Rainer Weikusat
Date:  
À: dng
Sujet: Re: [DNG] resolved
dev <devuan.2@???> writes:
>>> On Wed, 08 Jun 2016, Edward Bartolo wrote:
>>> fortunately they have a link to offer to non-subscribers, I'm not sure
>>> it will expire, however see here
>>> https://lwn.net/SubscriberLink/690151/721a817ed6377ec3/
>
>
> FTFA:
> "Lennart Poettering sees process persistence as a security issue."


'$person claims X was true' is not the same as '$person thinks X is
true'.

[...]

> Systemd isn't going to stop until it resemebles nothing like a classic
> *nix system.


That's a very bad way of framing this because it immediately lands you
in "stupid old farts resistant too ..."/ "This is 40 years old
technology!" territory. There are (as far as I know) two ways to create
a background process on UNIX(*), namely

    - a program may ignore or handle SIGHUP hence, it won't be
          terminated by the SIGHUP which is automatically sent to all
          members of a session upon logout


    - a program can use a fork to ensure that it's not a process
          group leader followed by setsid to make it run in its own
          session, hence, it won't get SIGHUP when the login session is
          destroyed


Neither of both is a privileged operation, hence, any user can create
background processes using whatever system resources said user is
allowed to use (eg, the number of processes or the cpu time could be
restricted).

Mr Poettering claims to believe users should need explicit permission
from 'the system administration' before they're allowed to create
background processes. I haven't seen a reason for this, though, and it's
somewhat unclear what such a reason could be. Eg, assuming I'm allowed
to compile a kernel on system ... now, why shouldn't I be allowed to
instruct the system to compile the same kernel while I'm asleep at 3am
in the morning provided this doesn't exceed system resources usually
available to me?

This is a useful feature which has been available on
many different kinds of systems in a certain way for a long time and a
lot of existing software relies on it. Hence, any change of behaviour
should provide a striking, practical advantage in order to justify the
cost. And abstract ideas of "theoretical OS purity" of isolated people
or groups of people are not a striking, practical advantage.