[PATCH] contrib/selinux: use regex instead of non-standard bash macro

[PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Danish Prakash]

It might be possible to avoid using non-standard bash macro (%USERID),
and instead using regex to match user ids. This would also mean
discarding the explicit restorecon call while packaging[1].

[1] - https://passt.top/passt/commit/?id=e019323538699967c155c29411545223dadfc0f5

Link: https://bugzilla.suse.com/show_bug.cgi?id=1246291
Signed-off-by: Danish Prakash <contact@danishpraka.sh>
---
 contrib/fedora/passt.spec | 11 -----------
 contrib/selinux/pasta.fc  | 12 ++++++------
 2 files changed, 6 insertions(+), 17 deletions(-)

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
@@ -103,17 +103,6 @@ fi
 
 %posttrans selinux
 %selinux_relabel_post -s %{selinuxtype}
-# %selinux_relabel_post calls fixfiles(8) with the previous file_contexts file
-# (see selabel_file(5)) in order to restore only the file contexts which
-# actually changed. However, as file_contexts doesn't support %{USERID}
-# substitutions, this will not work for specific file contexts that pasta needs
-# to have under /run/user.
-#
-# Restore those explicitly, hiding errors from restorecon(8): we can't pass a
-# path that's more specific than this, but at the same time /run/user often
-# contains FUSE mountpoints that can't be accessed as root, leading to
-# "Permission denied" messages, but not failures.
-restorecon -R /run/user 2>/dev/null
 
 %files
 %license LICENSES/{GPL-2.0-or-later.txt,BSD-3-Clause.txt}
diff --git a/contrib/selinux/pasta.fc b/contrib/selinux/pasta.fc
index e60c6148f412..82dbcbe2b75e 100644
--- a/contrib/selinux/pasta.fc
+++ b/contrib/selinux/pasta.fc
@@ -12,11 +12,11 @@
 /usr/bin/pasta.avx2					system_u:object_r:pasta_exec_t:s0
 /tmp/pasta\.pcap					system_u:object_r:pasta_log_t:s0
 /var/run/pasta\.pid					system_u:object_r:pasta_pid_t:s0
-/run/user/%{USERID}/netns				system_u:object_r:ifconfig_var_run_t:s0
-/run/user/%{USERID}/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
+/run/user/[0-9]+/netns				system_u:object_r:ifconfig_var_run_t:s0
+/run/user/[0-9]+/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
 # In case XDG_RUNTIME_DIR is not set (i.e. no systemd user session) Podman falls
 # back to a location under /tmp
-/tmp/storage-run-%{USERID}/netns					system_u:object_r:ifconfig_var_run_t:s0
-/tmp/storage-run-%{USERID}/containers/networks/rootless-netns		system_u:object_r:ifconfig_var_run_t:s0
-/tmp/containers-user-%{USERID}/netns					system_u:object_r:ifconfig_var_run_t:s0
-/tmp/containers-user-%{USERID}/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
+/tmp/storage-run-[0-9]+/netns					system_u:object_r:ifconfig_var_run_t:s0
+/tmp/storage-run-[0-9]+/containers/networks/rootless-netns		system_u:object_r:ifconfig_var_run_t:s0
+/tmp/containers-user-[0-9]+/netns					system_u:object_r:ifconfig_var_run_t:s0
+/tmp/containers-user-[0-9]+/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
-- 
2.51.0

Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Stefano Brivio]

[Cc'ing Max and Paul for awareness]

Hi Danish,

On Thu, 16 Oct 2025 13:10:41 +0530
Danish Prakash <contact@danishpraka.sh> wrote:

> It might be possible to avoid using non-standard bash macro (%USERID),
> and instead using regex to match user ids. This would also mean
> discarding the explicit restorecon call while packaging[1].
> 
> [1] - https://passt.top/passt/commit/?id=e019323538699967c155c29411545223dadfc0f5
> 
> Link: https://bugzilla.suse.com/show_bug.cgi?id=1246291

Thanks for the patch. This link is private. Would you mind making a copy
with the essential information in another ticket, or file a different
ticket somewhere else (bugs.passt.top, or Podman's tracker...)?

> Signed-off-by: Danish Prakash <contact@danishpraka.sh>
> ---
>  contrib/fedora/passt.spec | 11 -----------
>  contrib/selinux/pasta.fc  | 12 ++++++------
>  2 files changed, 6 insertions(+), 17 deletions(-)
> 
> 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
> @@ -103,17 +103,6 @@ fi
>  
>  %posttrans selinux
>  %selinux_relabel_post -s %{selinuxtype}
> -# %selinux_relabel_post calls fixfiles(8) with the previous file_contexts file
> -# (see selabel_file(5)) in order to restore only the file contexts which
> -# actually changed. However, as file_contexts doesn't support %{USERID}
> -# substitutions, this will not work for specific file contexts that pasta needs
> -# to have under /run/user.
> -#
> -# Restore those explicitly, hiding errors from restorecon(8): we can't pass a
> -# path that's more specific than this, but at the same time /run/user often
> -# contains FUSE mountpoints that can't be accessed as root, leading to
> -# "Permission denied" messages, but not failures.
> -restorecon -R /run/user 2>/dev/null
>  
>  %files
>  %license LICENSES/{GPL-2.0-or-later.txt,BSD-3-Clause.txt}
> diff --git a/contrib/selinux/pasta.fc b/contrib/selinux/pasta.fc
> index e60c6148f412..82dbcbe2b75e 100644
> --- a/contrib/selinux/pasta.fc
> +++ b/contrib/selinux/pasta.fc
> @@ -12,11 +12,11 @@
>  /usr/bin/pasta.avx2					system_u:object_r:pasta_exec_t:s0
>  /tmp/pasta\.pcap					system_u:object_r:pasta_log_t:s0
>  /var/run/pasta\.pid					system_u:object_r:pasta_pid_t:s0
> -/run/user/%{USERID}/netns				system_u:object_r:ifconfig_var_run_t:s0
> -/run/user/%{USERID}/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
> +/run/user/[0-9]+/netns				system_u:object_r:ifconfig_var_run_t:s0
> +/run/user/[0-9]+/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
>  # In case XDG_RUNTIME_DIR is not set (i.e. no systemd user session) Podman falls
>  # back to a location under /tmp
> -/tmp/storage-run-%{USERID}/netns					system_u:object_r:ifconfig_var_run_t:s0
> -/tmp/storage-run-%{USERID}/containers/networks/rootless-netns		system_u:object_r:ifconfig_var_run_t:s0
> -/tmp/containers-user-%{USERID}/netns					system_u:object_r:ifconfig_var_run_t:s0
> -/tmp/containers-user-%{USERID}/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
> +/tmp/storage-run-[0-9]+/netns					system_u:object_r:ifconfig_var_run_t:s0
> +/tmp/storage-run-[0-9]+/containers/networks/rootless-netns		system_u:object_r:ifconfig_var_run_t:s0
> +/tmp/containers-user-[0-9]+/netns					system_u:object_r:ifconfig_var_run_t:s0
> +/tmp/containers-user-[0-9]+/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0

At a glance, this looks like a better solution regardless of the
reported issue. It sounds too good to be true, though, so I wonder if
Max remembers any reason why we couldn't do this in the first place.

-- 
Stefano

Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Max Chernoff]

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 <contact@danishpraka.sh> 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

> 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/.*	<<none>>
    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}/.+	<<none>>

    $ 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.

Thanks,
-- Max

Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Danish Prakash]

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 <contact@danishpraka.sh> 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/.*	<<none>>
>     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}/.+	<<none>>
> 
>     $ 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

Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Stefano Brivio]

Hi Danish,

On Mon, 27 Oct 2025 14:19:14 +0530
Danish Prakash <contact@danishpraka.sh> wrote:

> 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 <contact@danishpraka.sh> 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/.*	<<none>>
> >     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}/.+	<<none>>
> > 
> >     $ 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?

Sure. But back to my question about the original problem... what was
the original problem? :) Could it be something similar to:

  https://bugzilla.redhat.com/show_bug.cgi?id=2401764

?

In general, there are a bunch of current SELinux issues reported on
Fedora/RHEL (and I assume they would be exactly the same on
openSUSE/SLES):

  https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&columnlist=short_desc%2Cchangeddate%2Cbug_severity&component=passt&product=Fedora

and I'm trying to find out if this change might fix some of them. Most
of those are stuff I didn't investigate yet.

-- 
Stefano

Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Max Chernoff]

Hi Stefano,

On Mon, 2025-10-27 at 10:07 +0100, Stefano Brivio wrote:
> In general, there are a bunch of current SELinux issues reported on
> Fedora/RHEL (and I assume they would be exactly the same on
> openSUSE/SLES):
>
>   https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&columnlist=short_desc%2Cchangeddate%2Cbug_severity&component=passt&product=Fedora
>
> and I'm trying to find out if this change might fix some of them.

I _think_ that this change shouldn't affect the AVCs at all; the only
advantage is that it should mean that we won't need an explicit call to
"restorecon" in the RPM .spec file. So I don't think that this will
actually fix any of those bugs, but I'd certainly love to be proved
wrong.

> Most of those are stuff I didn't investigate yet.

Ah, but searching my logs, it looks like I'm able to reproduce 2374291
now. I'll add a comment there.

Thanks,
-- Max

Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Danish Prakash]

On 10/27/25 2:37 PM, Stefano Brivio wrote:
> Hi Danish,
> 
> On Mon, 27 Oct 2025 14:19:14 +0530
> Danish Prakash <contact@danishpraka.sh> wrote:
> 
>> 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 <contact@danishpraka.sh> 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/.*	<<none>>
>>>     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}/.+	<<none>>
>>>
>>>     $ 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?
> 
> Sure. But back to my question about the original problem... what was
> the original problem? :) Could it be something similar to:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=2401764
> 
> ?

Ah, sorry about that. No, it's not a functionality issue or a bug. It
was merely a few suggestions to improve the passt SUSE package from the
SELinux team at SUSE. Here are the suggestions:

1. building twice is quite a hack, setting a hardlink as in apparmor
would probably work as well and is less confusing
2.  running restorecon would be unnecessary if the passt upstream
selinux module would not use ${USERID} in pasta.fc (gets converted to
[0-9]+ anyway)
3. there is a %selinux_requires macro in selinux-policy-devel that
likely could be used instead of listing the Requires:, but okay we dont
enforce that atm

For #1 I can see that building twice is required in this case, and
unlike apparmor which can work with hardlinks, doing the same for
SELinux isn't possible with inodes in the picture.

#2 is what this patch is about, and #3 is SUSE-exclusive which I'm
fixing in parallel.


> 
> In general, there are a bunch of current SELinux issues reported on
> Fedora/RHEL (and I assume they would be exactly the same on
> openSUSE/SLES):
> 
>   https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&columnlist=short_desc%2Cchangeddate%2Cbug_severity&component=passt&product=Fedora
> 
> and I'm trying to find out if this change might fix some of them. Most
> of those are stuff I didn't investigate yet.
> 

Unfortunately no, I was notified of a few spec related errors from
colleagues, but I'm sure the errors would overlap, as you said. If
there's something I can help, please let me know, I'll be happy to
contribute.

regards
-- 
danishpraka.sh

Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Stefano Brivio]

On Tue, 28 Oct 2025 11:58:18 +0530
Danish Prakash <contact@danishpraka.sh> wrote:

> On 10/27/25 2:37 PM, Stefano Brivio wrote:
> > Hi Danish,
> > 
> > On Mon, 27 Oct 2025 14:19:14 +0530
> > Danish Prakash <contact@danishpraka.sh> wrote:
> >   
> >> 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 <contact@danishpraka.sh> 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/.*	<<none>>
> >>>     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}/.+	<<none>>
> >>>
> >>>     $ 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?  
> > 
> > Sure. But back to my question about the original problem... what was
> > the original problem? :) Could it be something similar to:
> > 
> >   https://bugzilla.redhat.com/show_bug.cgi?id=2401764
> > 
> > ?  
> 
> Ah, sorry about that. No, it's not a functionality issue or a bug. It
> was merely a few suggestions to improve the passt SUSE package from the
> SELinux team at SUSE. Here are the suggestions:

Thanks for sharing those.

> 1. building twice is quite a hack, setting a hardlink as in apparmor
> would probably work as well and is less confusing

Details as to why it doesn't work:

  https://passt.top/passt/commit/?id=a405d0c026582375448fe87c6e440eb0fd428dd7

> 2.  running restorecon would be unnecessary if the passt upstream
> selinux module would not use ${USERID} in pasta.fc (gets converted to
> [0-9]+ anyway)

Would you be so kind as to re-post this patch (Cc'ing Max and Paul) with
a commit message reflecting this, and without private links?

> 3. there is a %selinux_requires macro in selinux-policy-devel that
> likely could be used instead of listing the Requires:, but okay we dont
> enforce that atm
> 
> For #1 I can see that building twice is required in this case, and
> unlike apparmor which can work with hardlinks, doing the same for
> SELinux isn't possible with inodes in the picture.

Right, yeah, it's because labels are stored in extended attributes, and
those belong to inodes, not paths.

> #2 is what this patch is about, and #3 is SUSE-exclusive which I'm
> fixing in parallel.

If I recall correctly, that part of openSUSE spec file is roughly taken
from:

  https://passt.top/passt/tree/contrib/fedora/passt.spec

and I build openSUSE packages in my Copr repository too
(https://copr.fedorainfracloud.org/coprs/sbrivio/passt/), based on the
Fedora spec file.

I'm not sure if it's useful for many people (one can try out an
upstream release right away like that) but it's almost zero effort on
my side. In any case, if the change also applies to Fedora or openSUSE
packages from Copr I guess it would be nice to have a patch for that as
well.

> > In general, there are a bunch of current SELinux issues reported on
> > Fedora/RHEL (and I assume they would be exactly the same on
> > openSUSE/SLES):
> > 
> >   https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&columnlist=short_desc%2Cchangeddate%2Cbug_severity&component=passt&product=Fedora
> > 
> > and I'm trying to find out if this change might fix some of them. Most
> > of those are stuff I didn't investigate yet.
> >   
> 
> Unfortunately no, I was notified of a few spec related errors from
> colleagues, but I'm sure the errors would overlap, as you said. If
> there's something I can help, please let me know, I'll be happy to
> contribute.

Thanks. I still need to find a moment to go through all of them with a
bit more time and I'll let you know, in case.

Well, of course, if you want to have a look meanwhile, that might help.
You would need an account at bugzilla.redhat.com to comment but, well, I
have an account on bugzilla.suse.com, so... :)

-- 
Stefano

[PATCH v2] contrib/selinux: use regex instead of SELinux template

[Danish Prakash]

It might be possible to avoid using SELinux template (%USERID),
and instead using regex to match user ids. This would allow
discarding the explicit restorecon call while during package builds[1].

Original suggestion from cathy.hu@suse.com:

> running restorecon would be unnecessary if the passt upstream selinux
> module would not use ${USERID} in pasta.fc (gets converted to [0-9]+ anyway)

[1] - https://passt.top/passt/commit/?id=e019323538699967c155c29411545223dadfc0f5

Signed-off-by: Danish Prakash <contact@danishpraka.sh>
---
 contrib/fedora/passt.spec | 11 -----------
 contrib/selinux/pasta.fc  | 12 ++++++------
 2 files changed, 6 insertions(+), 17 deletions(-)

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
@@ -103,17 +103,6 @@ fi
 
 %posttrans selinux
 %selinux_relabel_post -s %{selinuxtype}
-# %selinux_relabel_post calls fixfiles(8) with the previous file_contexts file
-# (see selabel_file(5)) in order to restore only the file contexts which
-# actually changed. However, as file_contexts doesn't support %{USERID}
-# substitutions, this will not work for specific file contexts that pasta needs
-# to have under /run/user.
-#
-# Restore those explicitly, hiding errors from restorecon(8): we can't pass a
-# path that's more specific than this, but at the same time /run/user often
-# contains FUSE mountpoints that can't be accessed as root, leading to
-# "Permission denied" messages, but not failures.
-restorecon -R /run/user 2>/dev/null
 
 %files
 %license LICENSES/{GPL-2.0-or-later.txt,BSD-3-Clause.txt}
diff --git a/contrib/selinux/pasta.fc b/contrib/selinux/pasta.fc
index e60c6148f412..82dbcbe2b75e 100644
--- a/contrib/selinux/pasta.fc
+++ b/contrib/selinux/pasta.fc
@@ -12,11 +12,11 @@
 /usr/bin/pasta.avx2					system_u:object_r:pasta_exec_t:s0
 /tmp/pasta\.pcap					system_u:object_r:pasta_log_t:s0
 /var/run/pasta\.pid					system_u:object_r:pasta_pid_t:s0
-/run/user/%{USERID}/netns				system_u:object_r:ifconfig_var_run_t:s0
-/run/user/%{USERID}/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
+/run/user/[0-9]+/netns				system_u:object_r:ifconfig_var_run_t:s0
+/run/user/[0-9]+/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
 # In case XDG_RUNTIME_DIR is not set (i.e. no systemd user session) Podman falls
 # back to a location under /tmp
-/tmp/storage-run-%{USERID}/netns					system_u:object_r:ifconfig_var_run_t:s0
-/tmp/storage-run-%{USERID}/containers/networks/rootless-netns		system_u:object_r:ifconfig_var_run_t:s0
-/tmp/containers-user-%{USERID}/netns					system_u:object_r:ifconfig_var_run_t:s0
-/tmp/containers-user-%{USERID}/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
+/tmp/storage-run-[0-9]+/netns					system_u:object_r:ifconfig_var_run_t:s0
+/tmp/storage-run-[0-9]+/containers/networks/rootless-netns		system_u:object_r:ifconfig_var_run_t:s0
+/tmp/containers-user-[0-9]+/netns					system_u:object_r:ifconfig_var_run_t:s0
+/tmp/containers-user-[0-9]+/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
-- 
2.51.0

Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Danish Prakash]

On 10/29/25 4:47 AM, Stefano Brivio wrote:
> On Tue, 28 Oct 2025 11:58:18 +0530
> Danish Prakash <contact@danishpraka.sh> wrote:
> 
>> On 10/27/25 2:37 PM, Stefano Brivio wrote:
>>> Hi Danish,
>>>
>>> On Mon, 27 Oct 2025 14:19:14 +0530
>>> Danish Prakash <contact@danishpraka.sh> wrote:
>>>   
>>>> 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 <contact@danishpraka.sh> 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/.*	<<none>>
>>>>>     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}/.+	<<none>>
>>>>>
>>>>>     $ 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?  
>>>
>>> Sure. But back to my question about the original problem... what was
>>> the original problem? :) Could it be something similar to:
>>>
>>>   https://bugzilla.redhat.com/show_bug.cgi?id=2401764
>>>
>>> ?  
>>
>> Ah, sorry about that. No, it's not a functionality issue or a bug. It
>> was merely a few suggestions to improve the passt SUSE package from the
>> SELinux team at SUSE. Here are the suggestions:
> 
> Thanks for sharing those.
> 
>> 1. building twice is quite a hack, setting a hardlink as in apparmor
>> would probably work as well and is less confusing
> 
> Details as to why it doesn't work:
> 
>   https://passt.top/passt/commit/?id=a405d0c026582375448fe87c6e440eb0fd428dd7
> 
>> 2.  running restorecon would be unnecessary if the passt upstream
>> selinux module would not use ${USERID} in pasta.fc (gets converted to
>> [0-9]+ anyway)
> 
> Would you be so kind as to re-post this patch (Cc'ing Max and Paul) with
> a commit message reflecting this, and without private links?

Sent updated patch, I wonder why it didn't show up in this thread, I did
include the message-id of the original message.

> 
>> 3. there is a %selinux_requires macro in selinux-policy-devel that
>> likely could be used instead of listing the Requires:, but okay we dont
>> enforce that atm
>>
>> For #1 I can see that building twice is required in this case, and
>> unlike apparmor which can work with hardlinks, doing the same for
>> SELinux isn't possible with inodes in the picture.
> 
> Right, yeah, it's because labels are stored in extended attributes, and
> those belong to inodes, not paths.
> 
>> #2 is what this patch is about, and #3 is SUSE-exclusive which I'm
>> fixing in parallel.
> 
> If I recall correctly, that part of openSUSE spec file is roughly taken
> from:
> 
>   https://passt.top/passt/tree/contrib/fedora/passt.spec
> 
> and I build openSUSE packages in my Copr repository too
> (https://copr.fedorainfracloud.org/coprs/sbrivio/passt/), based on the
> Fedora spec file.
> 
> I'm not sure if it's useful for many people (one can try out an
> upstream release right away like that) but it's almost zero effort on
> my side. In any case, if the change also applies to Fedora or openSUSE
> packages from Copr I guess it would be nice to have a patch for that as
> well.

Yes, the spec is taken from fedora. And now that you mention it, I can
see there's a similar %selinux_requires macro in fedora as well--taken
by openSUSE presumably. So I guess, I can send that change across as well.

> 
>>> In general, there are a bunch of current SELinux issues reported on
>>> Fedora/RHEL (and I assume they would be exactly the same on
>>> openSUSE/SLES):
>>>
>>>   https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&columnlist=short_desc%2Cchangeddate%2Cbug_severity&component=passt&product=Fedora
>>>
>>> and I'm trying to find out if this change might fix some of them. Most
>>> of those are stuff I didn't investigate yet.
>>>   
>>
>> Unfortunately no, I was notified of a few spec related errors from
>> colleagues, but I'm sure the errors would overlap, as you said. If
>> there's something I can help, please let me know, I'll be happy to
>> contribute.
> 
> Thanks. I still need to find a moment to go through all of them with a
> bit more time and I'll let you know, in case.
> 
> Well, of course, if you want to have a look meanwhile, that might help.
> You would need an account at bugzilla.redhat.com to comment but, well, I
> have an account on bugzilla.suse.com, so... :)
> 

Happy to help, I'll create that coveted account :)

-- 
danishpraka.sh

Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Stefano Brivio]

On Thu, 30 Oct 2025 14:07:16 +0530
Danish Prakash <contact@danishpraka.sh> wrote:

> On 10/29/25 4:47 AM, Stefano Brivio wrote:
> > On Tue, 28 Oct 2025 11:58:18 +0530
> > Danish Prakash <contact@danishpraka.sh> wrote:
> >   
> >> On 10/27/25 2:37 PM, Stefano Brivio wrote:  
> >>> Hi Danish,
> >>>
> >>> On Mon, 27 Oct 2025 14:19:14 +0530
> >>> Danish Prakash <contact@danishpraka.sh> wrote:
> >>>     
> >>>> 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 <contact@danishpraka.sh> 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/.*	<<none>>
> >>>>>     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}/.+	<<none>>
> >>>>>
> >>>>>     $ 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?    
> >>>
> >>> Sure. But back to my question about the original problem... what was
> >>> the original problem? :) Could it be something similar to:
> >>>
> >>>   https://bugzilla.redhat.com/show_bug.cgi?id=2401764
> >>>
> >>> ?    
> >>
> >> Ah, sorry about that. No, it's not a functionality issue or a bug. It
> >> was merely a few suggestions to improve the passt SUSE package from the
> >> SELinux team at SUSE. Here are the suggestions:  
> > 
> > Thanks for sharing those.
> >   
> >> 1. building twice is quite a hack, setting a hardlink as in apparmor
> >> would probably work as well and is less confusing  
> > 
> > Details as to why it doesn't work:
> > 
> >   https://passt.top/passt/commit/?id=a405d0c026582375448fe87c6e440eb0fd428dd7
> >   
> >> 2.  running restorecon would be unnecessary if the passt upstream
> >> selinux module would not use ${USERID} in pasta.fc (gets converted to
> >> [0-9]+ anyway)  
> > 
> > Would you be so kind as to re-post this patch (Cc'ing Max and Paul) with
> > a commit message reflecting this, and without private links?  
> 
> Sent updated patch, I wonder why it didn't show up in this thread, I did
> include the message-id of the original message.

Because you're not subscribed to the list so I have to approve your
posts manually, which might take a few minutes / hours. I just did that.

> >> 3. there is a %selinux_requires macro in selinux-policy-devel that
> >> likely could be used instead of listing the Requires:, but okay we dont
> >> enforce that atm
> >>
> >> For #1 I can see that building twice is required in this case, and
> >> unlike apparmor which can work with hardlinks, doing the same for
> >> SELinux isn't possible with inodes in the picture.  
> > 
> > Right, yeah, it's because labels are stored in extended attributes, and
> > those belong to inodes, not paths.
> >   
> >> #2 is what this patch is about, and #3 is SUSE-exclusive which I'm
> >> fixing in parallel.  
> > 
> > If I recall correctly, that part of openSUSE spec file is roughly taken
> > from:
> > 
> >   https://passt.top/passt/tree/contrib/fedora/passt.spec
> > 
> > and I build openSUSE packages in my Copr repository too
> > (https://copr.fedorainfracloud.org/coprs/sbrivio/passt/), based on the
> > Fedora spec file.
> > 
> > I'm not sure if it's useful for many people (one can try out an
> > upstream release right away like that) but it's almost zero effort on
> > my side. In any case, if the change also applies to Fedora or openSUSE
> > packages from Copr I guess it would be nice to have a patch for that as
> > well.  
> 
> Yes, the spec is taken from fedora. And now that you mention it, I can
> see there's a similar %selinux_requires macro in fedora as well--taken
> by openSUSE presumably. So I guess, I can send that change across as well.

Thanks, that would be nice.

> >>> In general, there are a bunch of current SELinux issues reported on
> >>> Fedora/RHEL (and I assume they would be exactly the same on
> >>> openSUSE/SLES):
> >>>
> >>>   https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&columnlist=short_desc%2Cchangeddate%2Cbug_severity&component=passt&product=Fedora
> >>>
> >>> and I'm trying to find out if this change might fix some of them. Most
> >>> of those are stuff I didn't investigate yet.
> >>>     
> >>
> >> Unfortunately no, I was notified of a few spec related errors from
> >> colleagues, but I'm sure the errors would overlap, as you said. If
> >> there's something I can help, please let me know, I'll be happy to
> >> contribute.  
> > 
> > Thanks. I still need to find a moment to go through all of them with a
> > bit more time and I'll let you know, in case.
> > 
> > Well, of course, if you want to have a look meanwhile, that might help.
> > You would need an account at bugzilla.redhat.com to comment but, well, I
> > have an account on bugzilla.suse.com, so... :)
> 
> Happy to help, I'll create that coveted account :)

-- 
Stefano

Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Stefano Brivio]

On Thu, 30 Oct 2025 09:43:46 +0100
Stefano Brivio <sbrivio@redhat.com> wrote:

> > > Would you be so kind as to re-post this patch (Cc'ing Max and Paul) with
> > > a commit message reflecting this, and without private links?    
> > 
> > Sent updated patch, I wonder why it didn't show up in this thread, I did
> > include the message-id of the original message.  

Can you please re-post Cc'ing Max and Paul? I can't do all this, it
doesn't scale, sorry.

-- 
Stefano

[PATCH v2] contrib/selinux: use regex instead of SELinux template

[Danish Prakash]

It might be possible to avoid using SELinux template (%USERID),
and instead using regex to match user ids. This would allow
discarding the explicit restorecon call while during package builds[1].

Original suggestion from cathy.hu@suse.com:

> running restorecon would be unnecessary if the passt upstream selinux
> module would not use ${USERID} in pasta.fc (gets converted to [0-9]+ anyway)

[1] - https://passt.top/passt/commit/?id=e019323538699967c155c29411545223dadfc0f5

Signed-off-by: Danish Prakash <contact@danishpraka.sh>
---
 contrib/fedora/passt.spec | 11 -----------
 contrib/selinux/pasta.fc  | 12 ++++++------
 2 files changed, 6 insertions(+), 17 deletions(-)

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
@@ -103,17 +103,6 @@ fi
 
 %posttrans selinux
 %selinux_relabel_post -s %{selinuxtype}
-# %selinux_relabel_post calls fixfiles(8) with the previous file_contexts file
-# (see selabel_file(5)) in order to restore only the file contexts which
-# actually changed. However, as file_contexts doesn't support %{USERID}
-# substitutions, this will not work for specific file contexts that pasta needs
-# to have under /run/user.
-#
-# Restore those explicitly, hiding errors from restorecon(8): we can't pass a
-# path that's more specific than this, but at the same time /run/user often
-# contains FUSE mountpoints that can't be accessed as root, leading to
-# "Permission denied" messages, but not failures.
-restorecon -R /run/user 2>/dev/null
 
 %files
 %license LICENSES/{GPL-2.0-or-later.txt,BSD-3-Clause.txt}
diff --git a/contrib/selinux/pasta.fc b/contrib/selinux/pasta.fc
index e60c6148f412..82dbcbe2b75e 100644
--- a/contrib/selinux/pasta.fc
+++ b/contrib/selinux/pasta.fc
@@ -12,11 +12,11 @@
 /usr/bin/pasta.avx2					system_u:object_r:pasta_exec_t:s0
 /tmp/pasta\.pcap					system_u:object_r:pasta_log_t:s0
 /var/run/pasta\.pid					system_u:object_r:pasta_pid_t:s0
-/run/user/%{USERID}/netns				system_u:object_r:ifconfig_var_run_t:s0
-/run/user/%{USERID}/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
+/run/user/[0-9]+/netns				system_u:object_r:ifconfig_var_run_t:s0
+/run/user/[0-9]+/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
 # In case XDG_RUNTIME_DIR is not set (i.e. no systemd user session) Podman falls
 # back to a location under /tmp
-/tmp/storage-run-%{USERID}/netns					system_u:object_r:ifconfig_var_run_t:s0
-/tmp/storage-run-%{USERID}/containers/networks/rootless-netns		system_u:object_r:ifconfig_var_run_t:s0
-/tmp/containers-user-%{USERID}/netns					system_u:object_r:ifconfig_var_run_t:s0
-/tmp/containers-user-%{USERID}/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
+/tmp/storage-run-[0-9]+/netns					system_u:object_r:ifconfig_var_run_t:s0
+/tmp/storage-run-[0-9]+/containers/networks/rootless-netns		system_u:object_r:ifconfig_var_run_t:s0
+/tmp/containers-user-[0-9]+/netns					system_u:object_r:ifconfig_var_run_t:s0
+/tmp/containers-user-[0-9]+/containers/networks/rootless-netns	system_u:object_r:ifconfig_var_run_t:s0
-- 
2.51.0

Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro

[Danish Prakash]

On 10/30/25 3:36 PM, Stefano Brivio wrote:
> On Thu, 30 Oct 2025 09:43:46 +0100
> Stefano Brivio <sbrivio@redhat.com> wrote:
> 
>>>> Would you be so kind as to re-post this patch (Cc'ing Max and Paul) with
>>>> a commit message reflecting this, and without private links?    
>>>
>>> Sent updated patch, I wonder why it didn't show up in this thread, I did
>>> include the message-id of the original message.  
> 
> Can you please re-post Cc'ing Max and Paul? I can't do all this, it
> doesn't scale, sorry.
> 

Sorry about that. I've sent the patch again.

regards
-- 
danishpraka.sh

Re: [PATCH v2] contrib/selinux: use regex instead of SELinux template

[Max Chernoff]

Hi Danish,

On Thu, 2025-10-30 at 16:19 +0530, Danish Prakash wrote:
> It might be possible to avoid using SELinux template (%USERID),
> and instead using regex to match user ids. This would allow
> discarding the explicit restorecon call while during package builds[1].
>
> Original suggestion from cathy.hu@suse.com:
>
> > running restorecon would be unnecessary if the passt upstream selinux
> > module would not use ${USERID} in pasta.fc (gets converted to [0-9]+ anyway)
>
> [1] - https://passt.top/passt/commit/?id=e019323538699967c155c29411545223dadfc0f5
>
> Signed-off-by: Danish Prakash <contact@danishpraka.sh>
> ---
>  contrib/fedora/passt.spec | 11 -----------
>  contrib/selinux/pasta.fc  | 12 ++++++------
>  2 files changed, 6 insertions(+), 17 deletions(-)
> [...]

I've built and installed an RPM with this patch, and I can confirm that
everything works as expected. Plus, this new implementation seems much
cleaner than the previous one, so this patch LGTM.

Thanks,
-- Max

Re: [PATCH v2] contrib/selinux: use regex instead of SELinux template

[Stefano Brivio]

On Thu, 30 Oct 2025 16:19:13 +0530
Danish Prakash <contact@danishpraka.sh> wrote:

> It might be possible to avoid using SELinux template (%USERID),
> and instead using regex to match user ids. This would allow
> discarding the explicit restorecon call while during package builds[1].
> 
> Original suggestion from cathy.hu@suse.com:
> 
> > running restorecon would be unnecessary if the passt upstream selinux
> > module would not use ${USERID} in pasta.fc (gets converted to [0-9]+ anyway)  
> 
> [1] - https://passt.top/passt/commit/?id=e019323538699967c155c29411545223dadfc0f5

Applied, thanks for the patch and for following up!

Max, thanks for testing and reviewing, I took the liberty to translate
your comments into Tested-by: and Reviewed-by: tags as they clearly
seemed to indicate that.

-- 
Stefano

Re: [PATCH v2] contrib/selinux: use regex instead of SELinux template

[Max Chernoff]

Hi Stefano,

On Tue, 2025-11-04 at 22:13 +0100, Stefano Brivio wrote:
> Max, thanks for testing and reviewing, I took the liberty to translate
> your comments into Tested-by: and Reviewed-by: tags as they clearly
> seemed to indicate that.

Ah, thanks for that! I'm still fairly new to the patch-on-a-mailing-list
workflow, so is there something that I should have done differently?

Thanks,
-- Max

Re: [PATCH v2] contrib/selinux: use regex instead of SELinux template

[Stefano Brivio]

On Wed, 05 Nov 2025 03:28:22 -0700
Max Chernoff <git@maxchernoff.ca> wrote:

> Hi Stefano,
> 
> On Tue, 2025-11-04 at 22:13 +0100, Stefano Brivio wrote:
> > Max, thanks for testing and reviewing, I took the liberty to translate
> > your comments into Tested-by: and Reviewed-by: tags as they clearly
> > seemed to indicate that.  
> 
> Ah, thanks for that! I'm still fairly new to the patch-on-a-mailing-list
> workflow, so is there something that I should have done differently?

We use pretty much the same tags as the Linux kernel does:

  https://docs.kernel.org/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes

(except we only use Link:, not Closes:) which are nice because they're
machine-readable, so one could use, say, for instance, a script like:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/get_maintainer.pl

to Cc: you automatically on a patch if you often reviewed or tested
the code or file affected by it.

So, here, you could have simply replied with:

    Reviewed-by: Max Chernoff <git@maxchernoff.ca>
    Tested-by: Max Chernoff <git@maxchernoff.ca>

to unequivocally state what you did with that submission.

Now, passt is small enough that we don't really have much of a use for
that at the moment, but it still sounds like a good idea in general,
also to future-proof things. It's also small enough that I can add /
fix tags as I merge patches without much fuss.

And yes, this should also be added to the new CONTRIBUTING.md file, I
have a growing list of small items to add and I'll do that in a batch
at some point. :)

-- 
Stefano

Re: [PATCH v2] contrib/selinux: use regex instead of SELinux template

[Max Chernoff]

Hi Stefano,

On Wed, 2025-11-05 at 16:31 +0100, Stefano Brivio wrote:
> On Wed, 05 Nov 2025 03:28:22 -0700
> Max Chernoff <git@maxchernoff.ca> wrote:
> > On Tue, 2025-11-04 at 22:13 +0100, Stefano Brivio wrote:
> > > Max, thanks for testing and reviewing, I took the liberty to translate
> > > your comments into Tested-by: and Reviewed-by: tags as they clearly
> > > seemed to indicate that.
> >
> > Ah, thanks for that! I'm still fairly new to the patch-on-a-mailing-list
> > workflow, so is there something that I should have done differently?
>
> We use pretty much the same tags as the Linux kernel does:
>
>   https://docs.kernel.org/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
>
> [...]
>
> So, here, you could have simply replied with:
>
>     Reviewed-by: Max Chernoff <git@maxchernoff.ca>
>     Tested-by: Max Chernoff <git@maxchernoff.ca>
>
> to unequivocally state what you did with that submission.

Thanks for the pointer! I'll make sure to remember that for next time.

Thanks,
-- Max