>>>>> Vincent Bernat <ber...@debian.org> writes:
>>>>> ❦ 30 novembre 2014 10:10 GMT, Ivan Shmakov <i...@siamics.net> :

[…]

 >> Or does the above concerns the users of “normally battery-powered”
 >> devices instead?

 > Previously, every DE would need to reimplement power management.
 > Now, this is handled by systemd (and hence not by the DE anymore).
 > Without any special configuration, closing the lid of a laptop will
 > put it to sleep except if there is still an active user on an
 > external display.

        Just to be clear: I do not use any laptops myself.  (Or anything
        else I’d need to put to sleep by closing its lid, for that
        matter.)

        I guess this means that this particular feature is of no use to
        me, right?  (And, as a consequence, that I may safely ignore it
        when deciding if I should retain my current init.)

[…]

 >>> Indirectly through PolicyKit: lots of functionality will be missing
 >>> if PolicyKit doesn’t have access to a console management interface.

 >> Specifically?

 > PolicyKit rely on logind to know if a user is locally connected.  A
 > non-local user won't be allowed things like network management, local
 > device mounting or sound card access.

        That looks like a problem to solve, not a feature.

        For home installs, I see no reason for the owner of the device
        to be /denied/ access to the sound card just because of using
        SSH.  Why, it’s exactly what I do.  (I even did things like
        $ ssh remote ogg123 /dev/stdin < local/file.ogg for various
        reasons in the past.)

        OTOH, for “workplace” installs, I see no reason for the user to
        be /granted/ access to the things like network management just
        because he or she happens to be logged in locally, – these
        privileges should rather be granted only to the person(s)
        responsible for that particular host.  (And then again, – SSH is
        a perfectly valid way to access to these facilities.)

        IIRC, D-I used to add the first non-root user it creates (which
        more or less is bound to happen to be the owner, or the person
        otherwise responsible for the host) to a number of groups (like
        audio or plugdev) to grant access to certain devices.  I know of
        no reason to abandon this practice.

        I agree that the issue gets trickier for multiuser hosts, but
        I’m pretty sure that there still will be at least one user for
        whom no such access restrictions should apply, – irrespective of
        his or her “login locality.”

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/873890onsa....@violet.siamics.net

Reply via email to