And to the list.. ---------- Forwarded message ---------- From: Wim Taymans <wim.taymans@xxxxxxxxx> Date: 18 March 2015 at 09:34 Subject: Re: [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>
