From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=gSKMg8+/; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id E91D15A0619 for ; Wed, 29 Oct 2025 00:17:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1761693430; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lcR3vn4GuojEhc0MZ44tGWMNrkfDkqqAFIv+wCbaEPk=; b=gSKMg8+/p3bC6K6cYpsDfZvYT61qFw8xww17LxBZfDGBPEuee6+sZAELU80rUFkvv1gUsr JTy07l231C7GdDaDdvqvhb2MFCq5PIOXwOi9ALe2r2w0Y6Rt8MOsmZ+s8rpPB20A74UZvr aolAL4LQvPvH68x9FK3rNeHIWJDJ+1w= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-602-HSn-FxRHP7iFm3BgBH5uUA-1; Tue, 28 Oct 2025 19:17:08 -0400 X-MC-Unique: HSn-FxRHP7iFm3BgBH5uUA-1 X-Mimecast-MFC-AGG-ID: HSn-FxRHP7iFm3BgBH5uUA_1761693428 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-475ddd57999so32750975e9.1 for ; Tue, 28 Oct 2025 16:17:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761693427; x=1762298227; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lcR3vn4GuojEhc0MZ44tGWMNrkfDkqqAFIv+wCbaEPk=; b=ubrCAnKS6XkEV22bqb8C9fBbkVRAS0LazojYhoiGUak3qgK6x3Ds20u2DI9y8DCXV3 yQD9Hq6uKWrEKDTHAi0lrDBIxVuDSlgJuEXZ6gNbcGiNEJCrDAF3+xRcHHfF/MnBAPMY 1ELrJF0tpAHV/iXd49w16npjPJiE3MnETRFdI8fQJJrEHo7OVlVZJEM49GwA8cLJqTKj whxpYWNzxNdoYbu3N8zli1rf6WMD3Hho3uVe/XpI4kPEFtGwUt4LEWUC8+UFj+nfphzF 9apz7aCkmBK9bb6BGZ95rZ3e7JqKkp+nTjPhzZafQu+jiCjC2jOYQo3MLmuVKlpmEHMv gaUw== X-Forwarded-Encrypted: i=1; AJvYcCXfVuGZlDtjSG7PGWVS082TsghGkeChxdMCdwrjDI0MGAPOy8Su9fESBXg59GWuaVlHNv/aIjdQEOs=@passt.top X-Gm-Message-State: AOJu0Yy1UlJF2+ppr2SkEI0GUONbUM1EywrKAHzK5TVS1t83JhiZgWZr kfcqyZjGYb62OUkKH/QfBfl70lPZa1Gol7wQdr5PX40zctzG87YWZmbRCXYzk3ulyM+SiaAiuHo L8TF1U/BySPFrdDRcIfL4kavgpdbZVC6cuqV82Uv8VD6Ee6uaCiAVQSp9z29DIQ== X-Gm-Gg: ASbGnct15mk1rjO6W7Tw4mLAzXiqPCRA9bf9gsn8qyi/FedwywbrBHH8JrwQCbJPo/L T1ZQn2dACEeHtqZE0avdlyXy7twyrCwh5DaZVv8RkqKLci86aiJEawVEPiF2jRjeqBjCZ/kshyp mzEOtEk24vEl6M5xjuxKOcs5fdMk2VjsjDhu9XAIG9whzA18Lm2HwP0EFQeQKTJ4BNjqzm9eS/J wb1K8ssPFLG2mTSYetq1jH1GgvxRFOhMlH/4BwMnro9Rj4QCqBx+j57UtYfwCLPoSSB+Dw9MiDL LE622iJiM7KZ+2DKe2Uz3wJTQ2ICeB/erl5aiGy+odPsCWCjCGg8l93cIBT1Oi8TTEv2d2VRbDz NWOQmczp3SA== X-Received: by 2002:a05:600c:8487:b0:471:152a:e566 with SMTP id 5b1f17b1804b1-4771e183fecmr7957755e9.13.1761693426969; Tue, 28 Oct 2025 16:17:06 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGBHQg1obbekVk8V1Tsdpd9C1Ug8gjfWT2SR6/M6VtsDCewfsJzdaYg+JedAWNG3WxqM9/u7w== X-Received: by 2002:a05:600c:8487:b0:471:152a:e566 with SMTP id 5b1f17b1804b1-4771e183fecmr7957565e9.13.1761693426512; Tue, 28 Oct 2025 16:17:06 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4771832e857sm32331615e9.0.2025.10.28.16.17.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Oct 2025 16:17:05 -0700 (PDT) Date: Wed, 29 Oct 2025 00:17:04 +0100 From: Stefano Brivio To: Danish Prakash Subject: Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro Message-ID: <20251029001704.43f73a42@elisabeth> In-Reply-To: References: <20251016074045.562352-1-contact@danishpraka.sh> <20251016102134.5e2edf04@elisabeth> <3aad50bb-aab8-423f-9730-21f9a3b3de78@danishpraka.sh> <20251027100721.46269f56@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 4GoGaSf3L_F7FH0iXNsM4TejrGO_eUQFV-VLip3-tBo_1761693428 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: TRFXEQL36VFFDPS4U4IUZI4POQB47ZEH X-Message-ID-Hash: TRFXEQL36VFFDPS4U4IUZI4POQB47ZEH X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Max Chernoff , 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 Tue, 28 Oct 2025 11:58:18 +0530 Danish Prakash wrote: > On 10/27/25 2:37 PM, Stefano Brivio wrote: > > Hi Danish, > > > > On Mon, 27 Oct 2025 14:19:14 +0530 > > Danish Prakash 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 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? > > > > 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