Reply is down thar ->
On 21/10/17 19:39, Michael Biebl wrote:
> Hi!
>
>
> 2017-10-21 19:28 GMT+02:00 Matthew Miller <mat...@mattdm.org>:
>> On Sat, Oct 21, 2017 at 03:40:40AM +0100, Ikey Doherty wrote:
>>> I've opted to make it an **alternative** backend to ease migration,
>>> thus:
>>>
>>> --with-backend=js|keyfile
>>
>> Nice. I'm personally super in favor of it. Not speaking for Red Hat
>> officially, by any means. From a pure Fedora point of view...
>> I don't think we have many users taking advantage of the javascript
>> format, but if there are, I would prefer to not break them.
>
> I'm very interested in this. I personally was never a huge fan of the
> JS based polkit version. mozjs is just a huge PITA.
> Martin Pitt, as co-maintainer of polkit in Debian, even less so, which
> is why all Debian and Ubuntu derived distros currently still use
> policykit 105 (+ a huge load of backported fixes).
>
> So far, we didn't have many users which came to us asking for the
> additional flexibility provided by the js-based rules.
> The notable exception is the Debian postgresql maintainer who wanted
> to use the the more granular polkit filtering that systemd allows.
> See the PR Jasper mentioned.
>
> Can something like this be expressed in the new keyfile format (at
> least to some extent)?
So to use the libvirt example:
polkit.addRule(function(action, subject) {
if (action.id == "org.libvirt.api.connect.getattr" &&
subject.user == "berrange") {
if (action.lookup("connect_driver") == 'QEMU') {
return polkit.Result.YES;
} else {
return polkit.Result.NO;
}
}
});
You'd express that as follows (when all is complete)
[Policy]
Rules=libvirt.custom.rules
[libvirt.custom.rules]
Actions=org.libvirt.api.connect.getattr
InUnixUsers=berrange
ExpectedKeys=connect_driver
ExpectedValues=QEMU
Result=yes
ResultInverse=no
The idea was to avoid PKLAs use of "ResultActive" "ResultInactive"
stanzas, and instead make each rule condition based with a given
outcome. Rules can be layered with various conditions to handle
other cases too. Just dupe the rule and alter the conditions
>
> That said, I'd be happy if this new keyfiles format would be something
> other distros (most notably Fedora/Redhat/openSUSE) could agree on. At
> least from the Debian side (and I assume by that extension Ubuntu)
> there definitely would be interest in having a common format again
> which is used by everyone and not as limited as the old pkla format.
>
> Regards,
> Michael
>
Aye, don't wanna repeat history, hence this new approach. Would also be
fantastic for upstream projects if they knew they could benefit from a
unified polkit format. (Another example being gvfs referencing 'wheel'
group which doesn't exist on all distros, hence the introduction of the
special '%wheel%' substitution)
- ikey
_______________________________________________
polkit-devel mailing list
polkit-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/polkit-devel
