From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=danishpraka.sh Authentication-Results: passt.top; dkim=pass (2048-bit key; unprotected) header.d=danishpraka.sh header.i=@danishpraka.sh header.a=rsa-sha256 header.s=fm1 header.b=FCqWeE8y; dkim=pass (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm3 header.b=u3n9npJ5; dkim-atps=neutral Received: from fout-a3-smtp.messagingengine.com (fout-a3-smtp.messagingengine.com [103.168.172.146]) by passt.top (Postfix) with ESMTPS id 8C5855A026F for ; Mon, 27 Oct 2025 09:49:30 +0100 (CET) Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfout.phl.internal (Postfix) with ESMTP id B244FEC01F9; Mon, 27 Oct 2025 04:49:29 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Mon, 27 Oct 2025 04:49:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danishpraka.sh; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm1; t=1761554969; x=1761641369; bh=9K5Fb2e2XFkLWl7YbLBBUhtotxyRkNzW rl905R6Vwwo=; b=FCqWeE8yEiE+kJbN+PdGjforyiqQBOy4VblC5N3Z3mssKEGm ujxCGAIzOpMM4xgCGUYrhN32mH+WxMGskvd6T1xcet3k2E3rhhHlgAlzLpyMCSn4 TYKKn/yuqZAlr/4QBieNVWIbBI89OHo9sn698CaAs+Be/lVdFEaN4Fo5Lb8cATgn BTcS7g8sYSgKAAhs7cS2hU6NRpn+a5nWIig4Oz8kjjJ494bJtG8on6mwCKDfWIFW L5sadgWH8pW06PA6iJyC3aLauml91UGDGSCB/S7UfqsGOXGgpAsx50P+c8RrRzSH 0f7VG4K7XxQhxzl8AqeXIAKfwAfTucUiX4EAbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1761554969; x= 1761641369; bh=9K5Fb2e2XFkLWl7YbLBBUhtotxyRkNzWrl905R6Vwwo=; b=u 3n9npJ5dlhniCDe17ywBNlxUNeHMIlyU/uiwF21YRknXnjxD/QGoeaRMdPVTKuPq N1/vkaCBE3+Sh/x9gPOD7jc+pc1FAMKkzMz6stVNfr9bHym7+80n7ctOrtvkC7St gGj3r2ud0iK/dVWtQKpbKynt3+X6ToHH+SXgiRUrDCnSO8NXo9/Q77oUOgpRAPTN OsPfpzgEKELsbnDYr9dtUtBAeoOunGFNr3Yf80DHAjzJ3chf5vYAyqQ9+QyZtINY rtNZYr/yaIIQY8kjKzDgbhETxMRENZzkO8DV8OBpNYKfc2PmVU9XV2g5tVueaJJK jTiGKNuHCGN1btg81nGyw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduheejheefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffrghnihhs hhcurfhrrghkrghshhcuoegtohhnthgrtghtsegurghnihhshhhprhgrkhgrrdhshheqne cuggftrfgrthhtvghrnhepheffieethfevvdejfeduffevteeftdfftedthfelkeettdfg jeeggffhgedvheeknecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtohhnthgrtghtsegurghn ihhshhhprhgrkhgrrdhshhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouh htpdhrtghpthhtohepghhithesmhgrgigthhgvrhhnohhffhdrtggrpdhrtghpthhtohep shgsrhhivhhiohesrhgvughhrghtrdgtohhmpdhrtghpthhtohepphgrshhsthdquggvvh esphgrshhsthdrthhophdprhgtphhtthhopehphhholhiiihhnghesrhgvughhrghtrdgt ohhm X-ME-Proxy: Feedback-ID: i59a6483a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Oct 2025 04:49:25 -0400 (EDT) Message-ID: <3aad50bb-aab8-423f-9730-21f9a3b3de78@danishpraka.sh> Date: Mon, 27 Oct 2025 14:19:14 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro To: Max Chernoff , Stefano Brivio References: <20251016074045.562352-1-contact@danishpraka.sh> <20251016102134.5e2edf04@elisabeth> Content-Language: en-US From: Danish Prakash In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-MailFrom: contact@danishpraka.sh X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: XXSBBD4X25XSJ2CB6INZMBOGL4M6LCBL X-Message-ID-Hash: XXSBBD4X25XSJ2CB6INZMBOGL4M6LCBL X-Mailman-Approved-At: Mon, 27 Oct 2025 10:13:39 +0100 CC: passt-dev@passt.top, Paul Holzinger X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 10/16/25 4:26 PM, Max Chernoff wrote: > Hi Stefano, > > On Thu, 2025-10-16 at 10:21 +0200, Stefano Brivio wrote: >> On Thu, 16 Oct 2025 13:10:41 +0530 >> Danish Prakash wrote: >>> It might be possible to avoid using non-standard bash macro (%USERID), > > It's not a Bash macro, it's a SELinux template. This doesn't seem to be > documented anywhere (which isn't terribly surprising with SELinux), but > it's defined in this file: > > https://github.com/SELinuxProject/selinux/blob/ceb5b221/libsemanage/src/genhomedircon.c Thanks Max, I wasn't aware of it being an SELinux template. > >> I wonder if >> Max remembers any reason why we couldn't do this in the first place. > > The Fedora SELinux policy always uses %{USERID}, and so I copied it from > there: > > $ grep -RnF '%{USERID}' policy/ > policy/modules/contrib/dbus.fc:29:/run/user/%{USERID}/bus -s gen_context(system_u:object_r:session_dbusd_tmp_t,s0) > policy/modules/contrib/dbus.fc:30:/run/user/%{USERID}/dbus(/.*)? gen_context(system_u:object_r:session_dbusd_tmp_t,s0) > policy/modules/contrib/dbus.fc:31:/run/user/%{USERID}/dbus-1(/.*)? gen_context(system_u:object_r:session_dbusd_tmp_t,s0) > policy/modules/contrib/gnome.fc:25:/run/user/%{USERID}/\.orc(/.*)? gen_context(system_u:object_r:gstreamer_home_t,s0) > policy/modules/contrib/gnome.fc:26:/run/user/%{USERID}/dconf(/.*)? gen_context(system_u:object_r:config_home_t,s0) > policy/modules/contrib/gnome.fc:27:/run/user/%{USERID}/keyring.* gen_context(system_u:object_r:gkeyringd_tmp_t,s0) > policy/modules/kernel/filesystem.fc:17:/run/user/%{USERID}/gvfs -d gen_context(system_u:object_r:fusefs_t,s0) > policy/modules/kernel/filesystem.fc:18:/run/user/%{USERID}/gvfs/.* <> > policy/modules/system/userdomain.fc:38:/run/user/%{USERID} -d gen_context(system_u:object_r:user_tmp_t,s0) > policy/modules/system/userdomain.fc:39:/run/user/%{USERID}/.+ <> > > $ grep -RnF '[0-9]+' policy/ | grep -v /dev/ > policy/modules/contrib/rpm.fc:52:/usr/bin/rhn_check-[0-9]+\.[0-9]+ -- gen_context(system_u:object_r:rpm_exec_t,s0) > policy/modules/contrib/soundserver.fc:12:/run/yiff-[0-9]+\.pid -- gen_context(system_u:object_r:soundd_var_run_t,s0) > policy/modules/kernel/devices.if:6958:## Allow read the hfi1_[0-9]+ devices > >>> diff --git a/contrib/fedora/passt.spec b/contrib/fedora/passt.spec >>> index 663289f53d97..d1bcf4a74338 100644 >>> --- a/contrib/fedora/passt.spec >>> +++ b/contrib/fedora/passt.spec >>> [...] >> >> At a glance, this looks like a better solution regardless of the >> reported issue. It sounds too good to be true, though > > I agree that it looks like a good solution, which makes me wonder why > the base SELinux policies don't do it that way. The containers SELinux > policy appears to do things this way > > $ grep -RnF '[0-9]+' > container_selinux.8:166: /run/user/[0-9]+/gvfs > $ grep -RnF '%{USERID}'; echo $? > 1 > > so it's probably (?) okay though. That's helpful, I guess we can go ahead with this. Stefano, Paul? > > Thanks, > -- Max -- danishpraka.sh