pipewire etc

pipewire etc

[Russell Coker]

Why do we need different policies for alsa, pipewire, and pulseaudio?  They 
all do the same things, why not just have an audioserver policy that supports 
all of them?

Why do we need an ifdef for server vs user operation of pipewire?  Why not 
just have a policy with a pipewire_t for the system daemon and pipewire_user_t 
for the user process?

https://wiki.archlinux.org/title/
PipeWire#Sharing_audio_devices_with_computers_on_the_network

For people wondering as I did why we even need a pipewire_user_t domain, the 
above section of the Arch Wiki documents sharing audio via Airplay and RTP 
among others - definitely need that isolated!

Is a pipewire_client_t domain just for the test program really useful?

It looks like the policy is well structured and replacing the cruft from years 
of support of alsa and pulseaudio is a good thing.  So I think we should go 
all the way and delete the separate policy for the old sound servers.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: pipewire etc

[Dominick Grift]

Russell Coker <russell@coker.com.au> writes:

> Why do we need different policies for alsa, pipewire, and pulseaudio?  They 
> all do the same things, why not just have an audioserver policy that supports 
> all of them?

Why change now? Pulseaudio has a troublesome past and design and
supporting that would affect the quality of the pipewire domain. Some of
the issues with pa may have improved over time but then the question is
where to draw the line with regards to compatibility.

>
> Why do we need an ifdef for server vs user operation of pipewire?  Why not 
> just have a policy with a pipewire_t for the system daemon and pipewire_user_t 
> for the user process?

https://github.com/SELinuxProject/refpolicy/pull/1109

In theory your suggestion is prettiest but it is probably debatable
whether its worth the extra work. Running pipewire as a system service
is fairly unusual and I do suspect that the two scenarios are
mutually exclusive any way.

>
> https://wiki.archlinux.org/title/
> PipeWire#Sharing_audio_devices_with_computers_on_the_network
>
> For people wondering as I did why we even need a pipewire_user_t domain, the 
> above section of the Arch Wiki documents sharing audio via Airplay and RTP 
> among others - definitely need that isolated!
>
> Is a pipewire_client_t domain just for the test program really useful?
>
> It looks like the policy is well structured and replacing the cruft from years 
> of support of alsa and pulseaudio is a good thing.  So I think we should go 
> all the way and delete the separate policy for the old sound servers.

-- 
gpg --auto-key-locate clear,nodefault,wkd --locate-external-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl