On Tue, 2014-12-16 at 13:40 +0100, Alexander Larsson wrote: > On tis, 2014-12-16 at 10:15 +0200, Tanu Kaskinen wrote: > > On Tue, 2014-12-16 at 09:48 +0530, Arun Raghavan wrote: > > > > > > On 15 Dec 2014 13:29, "Alexander Larsson" <[email protected]> wrote: > > > > > > > > On fre, 2014-12-12 at 17:42 +0100, Bastien Nocera wrote: > > > > > On Fri, 2014-12-12 at 17:08 +0100, Alexander Larsson wrote: > > > > > > On fre, 2014-11-28 at 16:07 +0100, Alexander Larsson wrote: > > > > > > > * Audio > > > > > > > > > > > > > > There is no audio support atm. Neither alsa libs, not device > > > > > > > nodes. > > > > > > > I think the best approach is to use pulseaudio, but this needs > > > > > > > careful consideration in terms of ABI/IPC compat, performance, > > > > > > > latency, etc. > > > > > > > > > > > > Today I looked at audio via pulseaudio. This is kind of tricky, it > > > > > > seems > > > > > > to me like the pulseaudio protocol follows the X11 style permissions > > > > > > method. I.e. if you're able to authenticate to the daemon you have > > > > > > full > > > > > > privs, including loading modules into the daemon. > > > > > > > > > > > > Furthermore, the "normal" mode of using shared memory to send audio > > > > > > relies on a single global /dev/shm, which breaks with any kind of > > > > > > containerization and allows any client to read any other clients > > > > > > data. > > > > > > > > > > > > I don't see why theoretically pulseaudio couldn't allow shared > > > > > > memory > > > > > > buffers in a contained mode, via e.g. fd passing of the shared > > > > > > memory > > > > > > instead of a shared namespace. However, anything like this involves > > > > > > upstream changes to the protocol. For now i'm disabling shared > > > > > > memory > > > > > > in the app, which is not ideal but at least allows apps to play > > > > > > sounds. > > > > In my experience the performance benefit of using shared memory in > > PulseAudio is small, so I wouldn't be too worried about disabling it. > > > > > > > Lennart did mention that PulseAudio could make use of kdbus for > > > > > passing > > > > > buffers around, and I guess that Wim's "PulseVideo" (for the lack of a > > > > > better name) could also make use of it. > > > > > > > > > > Finer permissions are necessary in any case. You can probably allow > > > > > any > > > > > app to play sound, but you might not want to allow microphone access > > > > > to > > > > > most applications. > > > > > > > > Yeah, this level of permissions will need some drastic changes to the > > > > pulseaudio client handling. Perhaps it is possible to do while keeping > > > > the protocol, not sure about that. But in general, a kdbus version would > > > > be pretty nice as this would remove the issues around having to > > > > share /dev/shm with the host. > > > > > > Yes, kdbus is something that could be useful to plug this leak (though > > > we'd also need to make sure we don't add much overhead). In general, > > > securing the protocol is something we'd like to have, but is a huge > > > can of worms right now -- securing the protocol post-facto will be > > > hard to do right. > > > > As I see it, the system for fine-grained permissions should be > > protocol-agnostic. Implementing that system is a lot of work. Adapting > > the current native protocol implementation to that is probably a smaller > > task - all commands already can fail for whatever reason, so it > > shouldn't be a big deal to add cases where they fail for "permission > > denied" reasons. > > Just denying an operation is not very hard. True. But in the current > protocol, how would you know what permissons profile to apply? We can't > depend on the uid as it will generally be the same. We should probably > base it on the cgroup of the remote peer, but there is currently no > race-free way to get that (only way is > getpeercred->pid->/proc/$pid/cgroup which is racy). kdbus does have > robust ways to get this (including other peer properties like selinux > context).
Ok, so kdbus would be beneficial, perhaps even required, as an authentication mechanism for sandboxed apps. So there are three layers to consider: 1) connection authentication, 2) the communication protocol and 3) the access control enforcement. kdbus code in PulseAudio could choose to implement only the authentication (after successful authentication, perhaps a pipe fd could be passed via kdbus and the old protocol would then take over, using the pipe as a transport), or the kdbus code could also implement a full D-Bus API so the old protocol wouldn't be involved at all. The access control enforcement part doesn't have to be specific to the kdbus protocol, but I can imagine that whoever implements the kdbus protocol might want to implement the access control enforcement inside the kdbus code to avoid doing big changes to the PulseAudio core code. -- Tanu _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
