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.