Comment 22 for bug 1224756

"So, I guess one could insert a check in the call to command_create_record_stream (src/pulsecore/protocol-native.c), that would deny access if trust-store says so."

Yes. I'm told that the latest in the lp:trust-store API turns this into ~10 lines of code (location-service will have the first example that can be looked at).

"However, there is still a way around that. Any app that can access the shm file can potentially look at audio data currently streaming to *another* app, i e, malicious app Eve can see what PulseAlice sends to the legitmate app Bob.
I'm not sure how much this SHM file is cleaned up (zeroed out) either, so there is a possibility the shm file contains old recorded data too."

Yes, but lets leave that to bug #1224751. We definitely want to clean up the SHM files, but I'm guessing this will be a longer term goal and I think this is mostly mitigated by application lifecycle on the phone since only the foreground app is allowed to run. It would be good for someone to look at the SHM file to make sure it didn't have previously recorded data.

"As for PulseAudio clients telling PulseAudio to access random files on the file system, I don't think that's true, but I could have missed something. Could you be more specific about where this functionality lies and I'll have a closer look?"

Ah, I was told this *may* be true and so I was stating in the bug that *if* it is true, then we need the additional apparmor integration. If it is not, then we don't. Based on your assessment, it sounds like it is not true.

"As for the LED, any app with access to both the LED and PulseAudio should be able to do this."

I think I wasn't clear-- apps currently don't have access to the LEDs, so I was thinking pulseaudio could potentially add this itself so the user had a visual cue that recording was happening (and said cue is outside of the app's control). This comment was intended for the design team-- I think we need design input before anyone implements this (not to mention, something in platform api that things like pulseaudio could use-- AFAIK, right now it is manipulating values in /sys. We would want to have a proper library for pulseaudio to use).