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

[Tanu Kaskinen]

On Wed, 2015-03-18 at 15:03 +0100, Wim Taymans wrote:
> 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.

Ok, so there are about 39 command handlers, and you'd rather modify
those so that each handler does only a synchronous call to the policy
module, rather than making those calls asynchronous.

Supposedly there are also about 39 places in the client code that can
now fail with PA_ERR_ACCESS, and each place will have to make a new
asynchronous call to the server to request more privileges, and then the
original operation has to be retried.

It doesn't sound to me like there would be any savings in terms of
changed lines of code.

> 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.

Yes, trying out both approaches with just a couple of commands sounds
like a good approach.

-- 
Tanu