[pulseaudio-discuss] [PATCH 0/5] Add access control to protocol-native

[Tanu Kaskinen]

On Fri, 2016-07-01 at 10:22 +0200, David Henningsson wrote:
> On 2016-07-01 03:30, Ahmed S. Darwish wrote:
> > On Fri, Jun 24, 2016 at 05:21:53PM +0200, David Henningsson wrote:
> > > Suppose the following chain of events:
> > > 
> > >   1. Protocol-native loads
> > >   2. Access control module loads, puts hooks into existing protocol-native
> > > instance
> > >   3. Protocol-native unloads
> > >   4. Another Protocol-native loads
> > > 
> > > At this point the new protocol-native is unprotected, which is probably not
> > > what you want?
> > > 
> > > Also we have to make sure we don't get use-after-free errors, no matter
> > > which order the modules are unloaded. But that's certainly solvable, just an
> > > additional thing to remember.
> > 
> > Can we solve the above two points by by introducing a pulse module
> > dependencies feature, just like what the linux kernel does? [1]
> > 
> > If so, we can do the following:
> > 
> > (a) Introduce module dependencies
> > 
> > (b) Put the access-control hooks inside protocol-native itself,
> >      and thus remove the 1-to-1 mappings [2] and avoid making core
> >      dependent on protocol-native (even implicitly)
> > 
> > (c) Make all policy modules, which contains all the hooks
> >      implementations, hard-dependent on protocol-native
> > 
> > In the first point raised, to unload protocol-native, user will
> > have to unload the dependent protocol-native-policy-X first. So if
> > the user loads protocol-native again, he/she will know that the
> > policy module will need to be reloaded as well ..
> > 
> > In the second point raised, hopefully module dependencies will
> > simplify the relationship: use-after-free errors can be eliminated
> > given proper cleanup by the policy modules ..
> > 
> > Any thoughts on this?
> > 
> 
> Just looking at core.h there seems to be both PA_CORE_HOOK_MODULE_NEW 
> and PA_CORE_HOOK_MODULE_UNLINK hooks, perhaps it could be as simple as 
> just requiring any access control module to listen to these and take the 
> appropriate action?
> 
> As for whether or not a generic "module dependencies" feature would be 
> good or bad: I would find it more user friendly myself if the user would 
> not have to manually reload access control modules, but since I'm not 
> that involved anymore, I don't think I should have decision power on 
> that matter. :-)

I agree that using MODULE_NEW and MODULE_UNLINK would be preferable to
a module dependency system if there actually was any danger of use-
after-free problems, but that issue doesn't exist. The access policy
module presumably holds a reference to the pa_native_protocol object,
which is a reference counted singleton, which will not be freed as long
as someone holds a reference. There's no 1:1 mapping to module-native-
protocol instances - there may be multiple instances loaded, but only
one pa_native_protocol object will ever exist.

-- 
Tanu