Polkit is a great idea, don't get me wrong. However:
* Like pretty much anything from freedesktop.org, the documentation is a joke.
* The security system implemented through it is next to impossible to debug. It's very easy to add "allow <this thing> to happen", but I can't do things like "ok, tell me who can mount filesystems" or "give me a list of all things that users in the wheel group are allowed to do". Normally this would be trivial to implement by parsing the rule files, except that the rules are written in JS (I have no idea why) and parsed in a particular, cumbersome order.
* Probably also as an artifact of having to execute JS code to add rules, many errors are silent, incomprehensible, or occur only when a particular action happens.
* polkit doesn't have a textual interface, it only works through D-Bus. This makes it useless for scripting.
> polkit doesn't have a textual interface, it only works through D-Bus. This makes it useless for scripting.
polkit(8) and pkcheck(1) describe how to use the pkcheck program. It returns 0 on success (access granted).
> I can't do things like "ok, tell me who can mount filesystems"...
I think that's the nature of the problem domain. polkit seems to be for enforcing arbitrary rules, when the built-in rules of something like sudo can't cope. Therefore: arbitrary code snippets as rules, therefore, no introspection.
However...
> ...or "give me a list of all things that users in the wheel group are allowed to do".
pkaction | grep mount
org.freedesktop.udisks2.filesystem-mount
org.freedesktop.udisks2.filesystem-mount-other-seat
org.freedesktop.udisks2.filesystem-mount-system
org.freedesktop.udisks2.filesystem-unmount-others
Gives a list of actions. Use pkcheck to probe for access.
# pkcheck --action-id org.freedesktop.udisks2.ata-standby
pkcheck: Subject not specified
<What the hell is a subject?>
# man pkcheck
/subject
<???>
It means to say that you have to specify a PID for which to check that. But the word "subject" doesn't even appear in the pkcheck manpage.
The synopsis also lists three possible forms for --process. However, only one of them is valid and (the developers currently think) presents no race conditions. There's a note warning that the other two are buggy, but they're still accepted for compatibility reasons, because those two (buggy) methods have been standard for years.
> I think that's the nature of the problem domain. polkit seems to be for enforcing arbitrary rules, when the built-in rules of something like sudo can't cope. Therefore: arbitrary code snippets as rules, therefore, no introspection.
I don't think it's the nature of the problem domain. The "arbitrary rules" can have a user- or group-base restriction. It's an architectural limitation that the system cannot go through the list of all currently enforceable rules and return those that match a particular user.
> However, [...] Gives a list of actions. Use pkcheck to probe for access.
The problem is that pkcheck verifies whether or not a certain process can execute a function. You can sort of hack it to do that, but it's not always effective.
By the way, the reason I need to be able to do it is the following gem:
> There is no guarantee that a function registered with addRule() or addAdminRule() is ever called - for example an early rules file could register a function that always return a value, hence ensuring that functions added later are never called.
This is extremely unpleasant, because you can (I have) run into problems of the following sort:
* I insert a rule with a particular priority that gets registered and runs. Ok, no problem.
* Later on, <some buggy software> inserts another rule which returns a value, thus terminating the rule chain before my rule gets to run.
Now all I find is that my own rule is not enforced, but I can't tell why that happens. There's no trivial way to trace the rule chain.
It also doesn't help that errors in rule files seem to go unreported. If you type "heel" instead of "wheel" for a group name, the whole thing will happily carry on, or at least I haven't yet figured out how to look for those errors.
* Like pretty much anything from freedesktop.org, the documentation is a joke.
* The security system implemented through it is next to impossible to debug. It's very easy to add "allow <this thing> to happen", but I can't do things like "ok, tell me who can mount filesystems" or "give me a list of all things that users in the wheel group are allowed to do". Normally this would be trivial to implement by parsing the rule files, except that the rules are written in JS (I have no idea why) and parsed in a particular, cumbersome order.
* Probably also as an artifact of having to execute JS code to add rules, many errors are silent, incomprehensible, or occur only when a particular action happens.
* polkit doesn't have a textual interface, it only works through D-Bus. This makes it useless for scripting.