Sudo and polkit are so complicated because they solve the wrong problem. The common problem is how do I execute code under a different effective user id. Instead they try to solve a much harder superset: how to securely implement a policy defining who is allowed to execute what under which effective user id in a setuid executable.
Polkit gets remarkably close. You can use polkit to define rules so an unprivileged user can call "systemctl restart ...", which sends an unprivileged message over D-Bus to pid 1, which checks authorization and then does the task if the requestor is authorized.
Polkit just also ships with pkexec and similar things in the sudo mindset.
The problem is that you have many things to configure instead of just one. That is a problem as we humans have a limited capacity for remembering things. On top of that polkit is basically javascript and xml (i think), and one can not expect everybody to understand javascript or have the patience to read/write xml. Now, in addition to groups and users (and advanced fs permissions and app/se/linux/armor), you have polkit and dbus permissions. This makes it really hard to look at something and know what it can do. For example steam, when you start it up, asks NetworkManager to bring up an internet connection. To disable that one has to write javascript.
In short, it's a clusterfuck. Even if everything worked properly (that is hard with Turing complete configuration files) it is still too vague, too big of a load to administrate. I expect the fd.o/fedora peoples answer to that (when people start complaining, that is) to be a GUI, not a rewrite.
I'm not going to defend polkit's choice of JS, but I have to say it's funny to see a complaint about Turing-complete configuration files when the usual anti-systemd sentiment prefers sysvinit Turing-complete shell scripts to systemd declarative configuration files :)
Do you have any real objections to what i said ? Did i even mention systemd or any sysvinit ?
Polkit is on systems with and without systemd. And, if you just have to pull sysvinit into it, shell scripts are simple (note that permissions to do something are not even remotely related to the shell scripting language as permissions in shell scripts are in the filesystem).
Less social, more technical. Please. Otherwise there is no hope of making things better.
I don't object to criticizing JS as an unusual choice. I agree with that.
I do object to the claim that declarative rules are better: the goal here is to reliably be able to express a security policy that means the same thing to the computer as to you. It would be difficult to find a sysadmin with no experience with either sudo or JS who would find sudoers rules more readable than JS. I found the experience of writing a polkit JS config pretty easy, especially since there are bunch of examples in the manpage: https://www.freedesktop.org/software/polkit/docs/latest/polk...
It's very common for someone to, say, not realize that a sudoers rule that lets you run /usr/bin/something also lets you run /usr/bin/something --with-arbitrary-args, but as soon as you provide a single argument that behavior goes away.
I definitely think you do want a simple language that lets you supply a few conditionals, maybe run some commands, and make decisions on that, and the best option is a real, existing language. Serious mistakes would include using M4, like sendmail, or writing your own scripting language, like Plymouth (https://www.freedesktop.org/wiki/Software/Plymouth/Scripts/).
I do think it'd also be good to have a system for extremely simple rules that doesn't involve writing JS, but I think the examples in the manpage mean the need for that is not very much.
I'd actually be inclined to suggest shell, given that it's familiar to sysadmins, but shell is notoriously bad at foolproof string handling, and that's exactly what you want to be able to enforce here. Failing that, perhaps Python (or Lua, but I'd bet more people are familiar with JS than Lua).
I'm reminded of proxy PAC files, which are also JS (because that was convenient for browsers; presumably JS was convenient here because GNOME has a JS library easily available). They're a weird system with some security concerns, but I don't think that the fact that they're in JS has ever been the problem with them.
Uh, so, systemd don't recommend to use `sudo systemctl start blah`. Their idea is to use `systemctl start blah` and have polkit handle the authentication. Not sure what's unclear here.
The difference is that with `sudo systemctl ...` systemctl is run as root, but with PolicyKit only parts are. And if I understand it correctly PolicyKit allows more fine grained control over permissions than sudo.
Well, since this was the recommendation from one of the polkit contributors... I'm not exactly sure what you mean. Perhaps you can enlighten me with your wisdom.
I think your being so quick to judge anything using JavaScript as inherently bad is silly, but this link just made me realize that using sudo with systemd as I had been seems to be incorrect, so thanks for the link.
Let's say you write some authorisation code using JavaScript. If it contains a syntax error, or a logic error your authentication is broken for your entire system. Checking the correctness of a program is usually non-trivial, but I accept some things CAN be checked (e.g. syntax). However, JavaScript, naturally is a procedural language and hence the bulk of your problems would be in your logic.
In contrast, /etc/sudoers{.d} config is syntactically validated using a strict grammar so that it can be validated for correctness before being loaded and used (hence visudo). It's primarily a declarative language too which means that logic bugs aren't really possible. This means that there is a robust mechanism to detect syntax issues (and some semantic issues) before breaking your system.
There are much simpler solutions without setuid: https://skarnet.org/software/s6/s6-sudo.html.