Le 25/02/2020 à 08:17, marc a écrit :
> Hello
>
>> I would like to add my point of view to the polkit debate.
> And they are well thought out comments :)
>
>> All things considered, I think for the purpose of interacting with system
>> level daemons/services and managing related permissions, especially in cases
>> more complex than simply shutting down the system for example, dbus + polkit
>> is a very nice solution, especially considering the alternatives. It does
>> have some flaws, though, such as noone knowing how to correctly configure
>> it, for example.
> I think that isn't quite enough to redeem polkit. I have the following
> reservations about it - it is written by the same/similar group that
> has written systemd, and many of their design decisions are very poor
> IMNSHO (I'd like use stronger words) and they have a habit of merging/entangling
> their code so that it becomes one big hairy mess. Devuan maintainers know
> how hard it is to disentangle that.
>
> On the systems I run, my first step is to remove avahi, pulse, systemd
> (thanks devuan), polkit, network manager and dbus. I find after that the
> system uses way less RAM and behaves more predictably - so when I configure
> it, it stays configured.
>
> The critique of polkit specifically relates to its poor config
> infrastructure - it is written in XML, this not only drags in another
> huge dependency, but is just ugly. XML was the fashion a decade or two
> ago, but is a bad idea for config files. It might be human readable,
> but barely so...
>
> The other problem of polkit and dbus is that it breaks the inheritance model
> of unix (a process is a child of some other one and inherits a subset of
> its capabilities, ignoring setuid). Changing this adds many complications,
> and makes chroot and containers a lot more complex to secure...
>
>> Regarding gksudo, I think it's intended use case is an awful thing as well.
>> The very Idea of asking for a users password for starting a more privileged
>> process is a bad one. It means that if the user account is breached, as soon
>> as sudo or gksudo is used to obtain root, it could have been replaced (z.B.
>> by changing the PATH, setting an alias, etc.) by an attacker to get the
>> password instead, and then compromise the rest of the system. In my opinion,
>> sudo should always be used in such a way as to work without password, and
>> only for known "safe" commands. For everything else, it'd be much better to
>> just log in on a tty as root. Same goes for su.
> No argument with that - that is a most sound argument. I would be
> nice if distributions could make that part of their standard documentation
> ("to upgrade a package, please press control-alt-F2, log in as root
> and type xxx"). There is even a fancy word we can use for "control-alt-F2",
> the "trusted path" or maybe even the "secure attention" keys. Maybe even
> reserve a certain tty so that a login there spawns the package management tool...
>
> regards
>
> marc

    Sorry, but synaptic is popular for a reason: it gives a large and
sensible view of packages, something apt or apt-get can't do.

    For what concerns aptitude, I've seen two persons able to make
sense out of it, but I never could.

        Didier