<div dir="ltr"><div>And to the list..</div><div><br></div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Wim Taymans</b> <span dir="ltr"><<a href="mailto:wim.taymans@gmail.com">wim.taymans@gmail.com</a>></span><br>Date: 18 March 2015 at 09:34<br>Subject: Re: [pulseaudio-discuss] [PATCH 0/2] access-control prototype<br>To: Tanu Kaskinen <<a href="mailto:tanu.kaskinen@linux.intel.com">tanu.kaskinen@linux.intel.com</a>><br><br><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 17 March 2015 at 20:37, Tanu Kaskinen <span dir="ltr"><<a href="mailto:tanu.kaskinen@linux.intel.com" target="_blank">tanu.kaskinen@linux.intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><br>
</div></div>No, I don't think it's possible to keep the main thread blocked while<br>
waiting for input from the user.<br>
<br>
We discussed this topic a bit in IRC today, and I got the impression<br>
that you and Arun have already experimented a bit with asking the user<br>
whether certain operations should be authorized. Arun told that instead<br>
of having just one asynchronous call to the policy module, it would be<br>
easier to implement one synchronous call for "basic checks" and if the<br>
basic checks fail, then an asynchronous call would be made for "full<br>
checks" (interactive). These patches don't contain either approach (only<br>
synchronous hooks are used), and I have trouble understanding what the<br>
problem is and how does introducing one extra call help in any way.<br>
Could you or Arun clarify?<br></blockquote><div><br></div></span><div>The problem is that we might have to ask the user for permission and that we</div><div>then would block the protocol-native command and thus also the main-loop.</div><div>We need a way to get back to the main-loop while waiting for the user input</div><div>and we explored 3 ideas:</div><div><br></div><div> - manually run the main-loop when waiting for user-input. We were not sure</div><div> if this is something the pulse mainloop would support so we didn't </div><div> investigate this further.</div><div><br></div><div> - make all commands support async replies. For this we would have to</div><div> change all command handlers to store their variables in a little struct, then</div><div> call the access hook with that struct. When the reply is ready to be sent we</div><div> would call the function to generate the reply. This is not very complicated but</div><div> it would result in more code to review. </div><div><br></div><div>- do synchronous calls to the access module and add a new command that</div><div> would allow async replies on the server and could thus be used to ask for</div><div> user input.</div><div> <br></div><div>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</div><div>database to decide if things are allowed or refused. When a command is</div><div>not allowed, a client simply gets an PA_ERR_ACCESS reply from the server.</div><div><br></div><div>This would then trigger our new AUTHORIZATION request for the failed action.</div><div>This new request would be implemented in such a way that the access module</div><div>can reply in an asynchronous matter (something like a context + finish method</div><div>is given to the hook, when the hook has the reply, it calls the finish method to</div><div>send the reply to the client). This new request would be called automatically by the</div><div>client library to give all clients the ability to ask for authorization. The advantage</div><div>of this new command is that we only have to add support for async replies</div><div>to this new command. The disadvantage is that we need another round trip and</div><div>some overhead in checking permissions twice.</div><div><br></div><div>The only reason for this new command would be because we can then avoid</div><div>making all command async on the server.</div><div><br></div><div>Maybe it is worth making a prototype of option 2 (maybe only for some commands)</div><div>to get an idea of the changes that are needed.</div><div><br></div><div>Wim</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br><span class="HOEnZb"><font color="#888888">
--<br>
Tanu<br>
<br>
</font></span></font></span></blockquote></div><br></div></div>
</div><br></div>