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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng