From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.sws.net.au (smtp.sws.net.au [144.76.186.9]) (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 5A4FA40D59B for ; Sat, 27 Jun 2026 00:09:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=144.76.186.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782519000; cv=none; b=Nytq4uYjORXr583DhVYJxqzEIAhXqOE4zstbUzPJi7HZ3IpmRI0Q/oerLkG/Ov8ulirQ6RKK4UYFTq2QwlzilOGvS8VwL75Ilr26jee7bZ/YlWyRmDIenLwO4PSwYc2KbCBUNX6NaiDYeN0kWZlPGDtbfJplVEo0nn8I4G3XeYw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782519000; c=relaxed/simple; bh=0SX3sFqXSLRPZ+U6d2dSnt4hFfGcd3Bi228uJkk1E28=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=sjgJLwExbQPDqiqU3ZFjO4e1oKkH/6Pdtbg5ft0q0Ob/o41JXwm7ky7H9/haUx2sBnx0S4QBb2cNy5hxBNft42h4dZBqmlestL7CxE4/9ZBYw9lhb3zFxWo5CsewaQsXtaW8w2m4UGAAQzlXOa0XaKW/Et/M0pLTlElMQA9GvtM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=coker.com.au; spf=pass smtp.mailfrom=coker.com.au; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b=jSuFDaiU; arc=none smtp.client-ip=144.76.186.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=coker.com.au Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=coker.com.au Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b="jSuFDaiU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1782518533; bh=L4buZtYQgnscYBqa3SlOJZyr4qiZqVfS+RAV0KhFqq8=; l=1044; h=From:To:Reply-To:Subject:Date:From; b=jSuFDaiUGu/o1QC99KzCcWPCSr7gXJH0SZ1BQV3G8FNbJFl3IaKqKIJzI3RiuCKFN twWh7Olg7kmXqYlibtNRPg/u7ZDJ3BIGC90FnggXrWjxyKdUYWoX9z/kblxtlhWRkw 7MOyy33bSVBH+v1JQ6k5zJ7GtH6CRRys40Z4ZdYM= Received: from xev.localnet (14-201-74-182.tpgi.com.au [14.201.74.182]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) (Authenticated sender: russell@coker.com.au) by smtp.sws.net.au (Postfix) with ESMTPSA id 26AE6110C9 for ; Sat, 27 Jun 2026 10:02:12 +1000 (AEST) From: Russell Coker To: selinux-refpolicy@vger.kernel.org Reply-To: russell@coker.com.au Subject: pipewire etc Date: Sat, 27 Jun 2026 10:02:09 +1000 Message-ID: <2540904.xDKz687JKs@xev> Precedence: bulk X-Mailing-List: selinux-refpolicy@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" 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/