Apologies, been epically busy here over at Solus. I've not done the PKLA parser and test suite yet, I can spend time on that this weekend if you wish.
- ikey On 15/12/17 22:23, Michael Biebl wrote: > Hi Ikey, > > I'd be very interested to hear updates on your efforts. > Has there been progress or did you run into issues? > > Regards, > Michael > > 2017-10-20 17:10 GMT+02:00 Ikey Doherty <i...@solus-project.com>: >> Hi, >> >> I'm Ikey Doherty, leader of the Solus project [1]. >> Yep, I know, yet another thread about replacing mozjs in polkit! >> Anyway, we've opted to tear out the existing JS backend entirely >> in Solus [2] - but we're not putting any JS providers back in. >> >> Instead we're going with a simpler, statically defined text format. >> This is "compiled" into a chain of structs when loaded, and policy >> tests are chained along file->policy->next file->next until such >> point as a break is achieved (i.e. not UNHANDLED) >> >> This is being actively developed right now, and we made a bit of noise >> about it on G+, so I'm here for two reasons. >> >> 1) Dispell rumours. We're not interested in a complete fork of polkit. >> 2) Explain the situation. >> >> I've seen a number of polkit alternatives spring up (such as Ostro's >> groupcheck) - however none still maintain full compatibility. Solus, >> being a desktop distro, still needs polkit agent, and the relevant >> API/ABI. >> >> Each rule will have a .desktop style file, which everyone loves [3], >> with well defined fields. Each rule may yield a Result when all of >> the specified conditions are met. A rule may also yield a ResultInverse >> as a blocking chain, however the action ID must first be matched: >> >> [Policy] >> Rules=libvirt.rules; >> AdminRules=polkit-default.admin >> >> [polkit-default.admin] >> InUnixGroups=wheel >> # InNetGroups=blah >> >> [libvirt.rules] >> Actions=org.libvirt.unix.manage >> InUnixGroups=libvirt >> Result=yes >> # Explicitly set a result if the condition is NOT matched >> # ResultInverse=auth_self_keep >> >> There are also fields to replace "subject.$field" accessors, i.e.: >> >> SubjectActive=true >> SubjectLocal=true >> >> Unlike a normal INI mapping, we don't test **defaults**. Instead, if >> the key is set to a value (true or false) we set a flag to our struct >> evaluation (policy->constraints & PF_CONSTRAINT_SUBJECT_ACTIVE) to >> make us validate against whatever the value is, offering the chance for >> a plain text file to be highly expressive. >> >> Our intention is that when this work is complete and tested in Solus, >> we'll want to upstream this. If the polkit development community is not >> interested in this, that's OK - we'll continue to carry the patches in >> Solus. However I would like to see this ideally in polkit itself, and >> dismiss the need for forks and alternatives, making polkit lightweight >> once more and even suitable for embedded environments. >> >> Anyway, rambly post over, I'd much rather be straight up early about >> what we're doing, before the rumour mill goes insane and thinks we're >> forking polkit permanently. :) >> >> Cheers! >> >> - ikey >> >> >> >> [1] https://solus-project.com/ >> [2] https://dev.solus-project.com/T4824 >> [3] Unless you use QSettings. >> _______________________________________________ >> polkit-devel mailing list >> polkit-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/polkit-devel > > > _______________________________________________ polkit-devel mailing list polkit-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/polkit-devel
