From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from markus.defensec.nl (markus.defensec.nl [45.80.168.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E304231A41 for ; Sat, 27 Jun 2026 06:23:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.80.168.93 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782541384; cv=none; b=sM7VlLbxI/hSOVqOibw92KMLy6JLFCqfrm+KXUvWP5CiJsFmF147TBxYEy5ts6s9Pgzm85yza7H9oPOW/1K5af8ultJMFzFFImHqqwmG9QbBwWKxT6iMHDsM9R1u6F4v403XqGcHjbXq3dT6g92OSBkwyXTUyT3w7Cn6Cd49PYA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782541384; c=relaxed/simple; bh=wxGJ7Waja5Q8wORNF0pktgJ0OBtQPYaXDNt+eqFFM/4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=My7n/s7gr5+z/luwNLtHfM5AaPhh618loRKO9lUEUZ3/hvFnkzosR5xKnaA+5u4xnQt3p+bBxEBGGfHeBlDgZxBahCrpk64WKPevuAgJiDZzRJabNfj1FghI8Ni54ZoW8OAQ5cjhOkmdIfMLBlWf5xnyBTjuoDfVg5mCha95i1Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=defensec.nl; spf=pass smtp.mailfrom=defensec.nl; dkim=pass (1024-bit key) header.d=defensec.nl header.i=@defensec.nl header.b=geOoBrLk; arc=none smtp.client-ip=45.80.168.93 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=defensec.nl Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=defensec.nl Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=defensec.nl header.i=@defensec.nl header.b="geOoBrLk" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=defensec.nl; s=default; t=1782541188; bh=wxGJ7Waja5Q8wORNF0pktgJ0OBtQPYaXDNt+eqFFM/4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=geOoBrLk2IPXAk1kRniM7Xy9aAiByFpQY9f0OmrC1W2EU9+52T4N4Zr4fYnbKzXl1 xIvTFYR9WiVMAAt+TsSBJwHbwPxR5gRmzbBs8OzCeV9YWsOFKODm6Ha8QpLEIRLTzq G9AZdYeYEL7K3psS9aMP1FgkNVMZK07QF4p+Ke3w= Received: from nimbus (nimbus.defensec.nl [IPv6:2a10:3781:2099::514]) by markus.defensec.nl (Postfix) with ESMTPSA id 648682B342B; Sat, 27 Jun 2026 08:19:48 +0200 (CEST) From: Dominick Grift To: Russell Coker Cc: selinux-refpolicy@vger.kernel.org Subject: Re: pipewire etc In-Reply-To: <2540904.xDKz687JKs@xev> (Russell Coker's message of "Sat, 27 Jun 2026 10:02:09 +1000") References: <2540904.xDKz687JKs@xev> Date: Sat, 27 Jun 2026 08:19:47 +0200 Message-ID: <87mrwgpksc.fsf@defensec.nl> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: selinux-refpolicy@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Russell Coker 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