remove polkit from core?

Miloslav Trmač mitr at volny.cz
Tue Nov 13 20:09:15 UTC 2012


On Tue, Nov 13, 2012 at 8:07 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> ----- Original Message -----
>
>> So, talking about specific actions...
>>
>> I have recently had to search all existing polkit policies.  This is
>> no longer possible to automate because various packages ship the
>> JavaScript policy, so I had to review those by hand.  It seems that
>> (perhaps with the exception of polkit itself) any use of JavaScript
>> could be converted into the old format, which remains supported.
>>
>> So, as soon I find some free time (probably next week), I intend to
>> ask FPC to prohibit using JavaScript if the functionality can be
>> represented in the old .pkla, and to prepare patches to convert the 6
>> JS-using packages.
>
> Not sure where you got that information. pkla files are not supported anymore.

My mistake - I meant the *.policy files in /usr/share/polkit-1/actions
, which definitely do affect system behavior.

> What is worthwhile doing though, is to review all existing packages that ship such rules, and stop them from doing that, if possible. JavaScript rules are only meant for admin use, no OS-provided package should install them.

Good, so we seem to agree on this part.  That would resolve my
concerns (ability to ability to analyze configuration shipped in
Fedora by a program), but not Steve's (ability to analyze admin's
customized configuration).

> A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in
Hm, I don't like that much.  Having two completely separate
authorization code paths in many software components makes it very
likely that the less frequently used code path will be buggy at least
in some components.
    Mirek


More information about the devel mailing list