# 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.
Ok, let's put it to a simple test :).
# 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.