[pulseaudio-discuss] Fwd: [PATCH 0/2] access-control prototype

[Wim Taymans]

And to the list..


---------- Forwarded message ----------
From: Wim Taymans <wim.taymans at gmail.com>
Date: 18 March 2015 at 09:34
Subject: Re: [pulseaudio-discuss] [PATCH 0/2] access-control prototype
To: Tanu Kaskinen <tanu.kaskinen at linux.intel.com>




On 17 March 2015 at 20:37, Tanu Kaskinen <tanu.kaskinen at linux.intel.com>
wrote:

>
> No, I don't think it's possible to keep the main thread blocked while
> waiting for input from the user.
>
> We discussed this topic a bit in IRC today, and I got the impression
> that you and Arun have already experimented a bit with asking the user
> whether certain operations should be authorized. Arun told that instead
> of having just one asynchronous call to the policy module, it would be
> easier to implement one synchronous call for "basic checks" and if the
> basic checks fail, then an asynchronous call would be made for "full
> checks" (interactive). These patches don't contain either approach (only
> synchronous hooks are used), and I have trouble understanding what the
> problem is and how does introducing one extra call help in any way.
> Could you or Arun clarify?
>

The problem is that we might have to ask the user for permission and that we
then would block the protocol-native command and thus also the main-loop.
We need a way to get back to the main-loop while waiting for the user input
and we explored 3 ideas:

 - manually run the main-loop when waiting for user-input. We were not sure
   if this is something the pulse mainloop would support so we didn't
   investigate this further.

 - make all commands support async replies. For this we would have to
   change all command handlers to store their variables in a little struct,
then
   call the access hook with that struct. When the reply is ready to be
sent we
   would call the function to generate the reply. This is not very
complicated but
   it would result in more code to review.

- do synchronous calls to the access module and add a new command that
   would allow async replies on the server and could thus be used to ask for
   user input.

So option 3 is what we're currently looking at in more detail. The idea is
that those hooks proposed in the patches, don't block but simply perform a
lookup into the
database to decide if things are allowed or refused. When a command is
not allowed, a client simply gets an PA_ERR_ACCESS reply from the server.

This would then trigger our new AUTHORIZATION request for the failed action.
This new request would be implemented in such a way that the access module
can reply in an asynchronous matter (something like a context + finish
method
is given to the hook, when the hook has the reply, it calls the finish
method to
send the reply to the client). This new request would be called
automatically by the
client library to give all clients the ability to ask for authorization.
The advantage
of this new command is that we only have to add support for async replies
to this new command. The disadvantage is that we need another round trip and
some overhead in checking permissions twice.

The only reason for this new command would be because we can then avoid
making all command async on the server.

Maybe it is worth making a prototype of option 2 (maybe only for some
commands)
to get an idea of the changes that are needed.

Wim



>
> --
> Tanu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20150318/cf9c5246/attachment.html>