<div dir="ltr">Hi guys,<div><br></div><div>I'm having another look at the access control patches. I revived my old</div><div>patches and found some trouble with the async stuff that I fixed here:</div><div><br></div><div>  <a href="https://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=access-hooks">https://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=access-hooks</a><br></div><div><br></div><div>There is also an example on how to start and complete an async access</div><div>check for starting a recording. I believe Ahmed Darwish is building on</div><div>top of that so it might be useful to get it working.</div><div><br></div><div>Now I'm taking a look at the info in pa_client that is available to decide</div><div>what access checks we need to do for each client.</div><div><br></div><div><div>Ideally we would need the pid of the process with we can currently find</div></div><div>in the pa_proplist of the client. Unfortunately this pid is whatever the client</div><div>sends us in a proplist in the set_client_name command so we need something</div><div>more secure.</div><div><br></div><div>We do send the pid and gid with the SCM_CREDENTIALS ancillary data in</div><div>the AUTH command. Since the kernel checks things, we can be guaranteed</div><div>that when we get the credentials, they are correct. </div><div><br></div><div>What I would like to do is make these credentials available somewhere. I</div><div>would like to make a new key in the client proplist with the verified pid from</div><div>the credentials but the problem is that we then need to make sure that a</div><div>set_client_name command can't overwrite the value, which involves some</div><div>filtering or keys.</div><div><br></div><div>Alternatively we could make a new pa_client field to store the verified pid</div><div>and gid.. Does this sound better or worse?</div><div><br></div><div>Wim</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>