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=d0HnmC5y; 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 51BBF5A026F for ; Mon, 27 Oct 2025 10:07:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1761556053; 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=1wk+IApKk7KCMEjo7zeBnWniZKLan2NNIAASP/s1Bss=; b=d0HnmC5yhY5e/WhM65bho14C7boYMrYLNqoYi/FxtWg+wlDycyixPL81+vfobhlypzX5Ff DWqL15s6jopBymE68IdXrSY//xlU9Wr4whDA86UFmsXESTcRtaMREfDEETbdpL+RakQHVc g6IHIR2+Fzm8ng8ryH8U7u4Lg4qYUW8= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-304-U8RDV_eKPJ6cZRwEG3J5zA-1; Mon, 27 Oct 2025 05:07:31 -0400 X-MC-Unique: U8RDV_eKPJ6cZRwEG3J5zA-1 X-Mimecast-MFC-AGG-ID: U8RDV_eKPJ6cZRwEG3J5zA_1761556051 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-428566218c6so1931836f8f.0 for ; Mon, 27 Oct 2025 02:07:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761556050; x=1762160850; 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=1wk+IApKk7KCMEjo7zeBnWniZKLan2NNIAASP/s1Bss=; b=uNgKpfcjsVDnFB2/9h2+/12Y58Pl6/0tH/4f9awD7yZzGygecu1uTMuJTKcinqOk0G Leoq80Lrv0xYSoTTutDLVTdJotYq8IQqdrtBvT+gYvnWQ9DEnQ3O4DpbCbmxR3+oJSxV kvV95mg8VRVXHIIIHmNZKEljczYJpoXSS15dJg9f5xUee62W2pAlbK7P4b0zOUMTPwEk ld4HozJkkFImP17oXT/N9kSCsj/aVsasCFEGN7kfhlENG+g0Xz5pMwA0L/pDdW0qjzw0 /HFBfB9SOPSJuDQv9rk8MyCyja16ZHtzQB8zCHlFtm6w5Y8SpF+1SeXHP5rmT0AIMVsd Zfhw== X-Forwarded-Encrypted: i=1; AJvYcCXrnqa4g/Db9Dkd404xLMuN7SM9oqGMLc7WY3rzpMeL2yiFSn+d6ekuDFbQktVPtCMFWEoC8NMRz00=@passt.top X-Gm-Message-State: AOJu0Yxx5UB61Dx7WS228j+YBGJ/pGw52QW4GRAWastZWh1/REsGbo5M npJlz8orhPKvDN2ZdQH/OxumMBiHgqmveZ4Qzt+RTmPOh4+HWv1ztRNbbHkzudNqcPMnLirtL9W jPKtzc/YAT6Nq7Ihmn7cNsS/Vtdj+eR2JYBMuY1/gSrL5bAKsqr5wqAunHSGZgA== X-Gm-Gg: ASbGncvNNCkxkWf44y4Zu2pWu0L5e8U8FyvRykLy0tvtnGcL1v0Q7pnbL6ZJDjLNySO FP5DTXsrv2ylQwfGUfVDJ+pFzvCwFyTPcTAh3etq1OWDKBfRPMGvXI0umW7YF6Bkz3jySoS+L4c LYM9FjM6hkPbyH6rarzyG1hFtmii3jzty/emTf50Ddjb0O9PkmxItKbTVYkSFnBEH8YRcUTbEe6 BzKmQQaVg4AKHytfbpleiu8F9lLvD1JOwcB7edVbcO4ysDSfS8u7rp2AKtBGzvr9uH3+YxQviqo 6MWcI3rV8y1Cr14sGVwVJ35otGHYNqWHNHqg7MrBba00bomJn3Z0xgSDjnIDmCPDuheKjwSnetG /r4yiqs/TnA== X-Received: by 2002:a05:600d:42cc:b0:471:9da:524c with SMTP id 5b1f17b1804b1-475cafae8fbmr73643115e9.12.1761556049695; Mon, 27 Oct 2025 02:07:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEgA7D98gp2Oki4Ett1+q/GhTZAIg6JsjeBS46Bz+fGAqb8LWFPxkiOqkMa4MsrovYGkZ7vsA== X-Received: by 2002:a05:600d:42cc:b0:471:9da:524c with SMTP id 5b1f17b1804b1-475cafae8fbmr73642745e9.12.1761556048628; Mon, 27 Oct 2025 02:07:28 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-475ddab580esm59885325e9.7.2025.10.27.02.07.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Oct 2025 02:07:27 -0700 (PDT) Date: Mon, 27 Oct 2025 10:07:21 +0100 From: Stefano Brivio To: Danish Prakash Subject: Re: [PATCH] contrib/selinux: use regex instead of non-standard bash macro Message-ID: <20251027100721.46269f56@elisabeth> In-Reply-To: <3aad50bb-aab8-423f-9730-21f9a3b3de78@danishpraka.sh> References: <20251016074045.562352-1-contact@danishpraka.sh> <20251016102134.5e2edf04@elisabeth> <3aad50bb-aab8-423f-9730-21f9a3b3de78@danishpraka.sh> 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: znML1F7t7sDgrTGQ1ZPHKLlbWihH3uWN44qDmqAHQC4_1761556051 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: TNO2RZ5L5YXSKQ6K737BVSQ7BL3ICK24 X-Message-ID-Hash: TNO2RZ5L5YXSKQ6K737BVSQ7BL3ICK24 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: 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 ? 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