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
_______________________________________________
polkit-devel mailing list
polkit-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/polkit-devel
