Replacing polkit JS backend

[Simon McVittie]

On Wed, 03 Jan 2018 at 17:07:03 +0100, Miloslav Trmac wrote:
> See one of the other mails, I’m worried that with the vaguely systemd-like ”no
> programming language, but a few ‘simple’ special-cased condition operators”
> systems never stay simple.

This is a valid concern.

> more and more Condition* operators which will be difficult to consume by any
> automated analysis

True; but on the other hand, Turing-complete programming languages are
difficult to analyze too, and impossible to consume without executing them
(if nothing else because of the halting problem).

> What is the separator? What is the escaping mechanism for including the
> separator inside the values?

These two, at least, are a solved problem if the format recycles
freedesktop.org Desktop Entry syntax, as implemented by GLib's GKeyFile.

(Note that systemd doesn't do that, and has its own orthogonal format;
systemd units and fd.o desktop entries were both inspired by Windows .ini
files, but they extend the .ini format differently.)

Your other concerns about unclear syntax are valid. I would personally
tend to try to spell anything key-value-shaped as a group, like Flatpak
does:

    [Session Bus Policy]
    com.example.Foo=own
    org.example.Bar=talk

but that can get ugly when other groups want to refer to it.

> I view the centralized "send all data about the operation to a central daemon,
> and have a central generalized mechanism to make a decision" model as a mistake
> from the start. It seems much more natural to me if "the qemu driver object in
> libvirt, read access" conceptually had a dumb ACL attached. (That ACL could
> still be centrally stored, or at least centrally enumeratable, if that seemed
> like a valuable property to someone; I don’t see a strong case for it so far.)

So instead of (e.g.) libvirtd using libpolkit-gobject-1 to talk to polkit,
which might talk to the polkit prompting agent before replying, you'd make
libvirtd use libsome-new-policy, which might either answer "yes" or "no"
immediately, or talk to the active user's prompting agent directly
if the answer is "you need to ask"?

As I described in http://smcv.pseudorandom.co.uk/2015/why_polkit/ I
believe the main problems polkit aims to be solving are:

- NetworkManager, libvirtd, udisks, etc. should share a "language" and
  location for their ACLs, so that sysadmins and OS integrators who know
  how to configure one know how to configure them all

- If a new interesting fact about users is identified, it shouldn't be
  necessary to patch NetworkManager, libvirtd, udisks etc. before that
  fact can be used in their ACL rules (for example if someone wants the
  AppArmor profile of the requesting process to be an input to the ACL
  evaluation, they only have to add that feature once, rather than once
  per daemon)

Those don't inherently prevent polkit from being implemented as a simple
library, of course.

Some possible motivations for polkitd being a daemon (I'm sure there
are many more, these are just the ones I thought of):

- If the ACL-evaluation language uses large or inconvenient libraries
  (hello mozjs), those libraries don't have to be in everyone's process
  space (potentially interfering with a different version of mozjs that
  the service in question might use as an extension language, etc.)

- The exact rules used can be kept confidential and not exposed to the
  services or to random uids (of course daemons can query the rules
  repeatedly and use that as an oracle, but if that's considered a
  threat, polkit can rate-limit them or log an audit trail of failed
  attempts)

- Letting polkit talk to random user accounts' prompting agents is less
  scary (and easier to express in the rather limited dbus-daemon ACL
  language) than letting every system service talk to random user
  accounts' prompting agents

    smcv