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