2018-01-03 19:47 GMT+01:00 Simon McVittie <s...@collabora.com>:
> 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).
>
Oh, I am absolutely not defending the JavaScript. I’m trying to argue that
the policy language should be extremely simple and nonextensible.
Extensibility should belong in the application logic deciding which policy
element to apply. (And to be fair, there is a counterargument in that RBAC
models sometimes force admins to autogenerate thousands or more ACL entries
to express a “simple little program”.)
> 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"?
>
This is not primarily an *implementation* preference. That
libsome-new-policy could also forward all processing to a central
ACL-storing and ACL-evaluating daemon. That’s an implementation detail as
far as applications are concerned; as you say, e.g. maybe for privacy
reasons the traditional polkit “is user X currently physically at the
console” data point, or other data necessary to evaluate ACLs, should not
be available for random processes to read. Also auditing, or perhaps other
concerns may force the ACL evaluation to happen in a central place.
The point is that the proposed *model* is "this printer has a pretty dumb
ACL for users who are allowed to print; here is a handle to the ACL, and a
handle to the client asking to print; is this allowed?", not “there is a
print-to-printer operation; here is a string:string map with a thousand
details about the users’ connection and printer attributes, and BTW also a
handle to the client asking to print; is this allowed?” The application
specifics become a matter of the application deciding which ACL to refer
to, not a data point for the ACL language to interpret. (In theory this
could tempt some applications to design their private “which ACL to use for
this operation” programming language, which would be worse than a central
one in polkit. My hope is that nobody would do that.)
Mirek
_______________________________________________
polkit-devel mailing list
polkit-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/polkit-devel
