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=OfoEA1c8; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 431735A0272 for ; Tue, 07 Apr 2026 19:51:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775584307; 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=FCqHDtkfAgxZaFYJF3Qu8OmUSWIR+wmZFBmWmL3OTko=; b=OfoEA1c8XxAIbtM32G0dxVSl7LYd892EEembUxUv7WVVYTEbO7RRW6NnXhBbrx336CTDKi WfQakNb4OQVyQ2ERvx/h3cGbmsbEXq/KUoECNborNBDCbfIOK1/Esi2BTzk2M6ZrkymA+m 5MrFwtxH/awWOIG87ZHt0zxZlcENnW0= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-155-kS9lQ1VQMD2B_igeLgwlAA-1; Tue, 07 Apr 2026 13:51:45 -0400 X-MC-Unique: kS9lQ1VQMD2B_igeLgwlAA-1 X-Mimecast-MFC-AGG-ID: kS9lQ1VQMD2B_igeLgwlAA_1775584305 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-488c2aa6becso4426235e9.2 for ; Tue, 07 Apr 2026 10:51:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775584304; x=1776189104; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FCqHDtkfAgxZaFYJF3Qu8OmUSWIR+wmZFBmWmL3OTko=; b=k0TRCz+fsv6/LF/8UqaSpNCrJAHHDJB5hNWsl+muJOTI68cT/Pt1b5zLQu1Hbpifc7 uy64iCPkntjDXrg2ZI4cfCsYo0JnodcjRPRXTIxZu0Br0AjFbqXBpYBApP0QGtwAXkbv N+SL6yN1uBtFLuulFdFaWVVScJnbqJSh7tDz6Q8ZoLwPlvv6wL7zWN4DGmYp/Z31Qblf TjCCqwz9Z7mIe8ZsFRJzH0CFg7aV9gxVWYHhMSRDe1tqLWgth+WzknSdxyiZW7s2JsKQ a2WlZfm6hk2WAvjifeK/619EcE2XTM4E7/gA6rQYaUrJLgWY+FfaMpinRDDd26Kl1mBl EAZQ== X-Gm-Message-State: AOJu0YxP9RzLwESTQhOQewXAbO5GGHhnq/+HarcfYNFGgLyzQn83oJ+Z U6TGmD1A7ZpVFcMGjT4pN/AejsNX5wob4tjEQGKpjFEzHabzxea2Ny2QIWulxa0dNSP8vbLwDhz dB3FyqpinbSURgE/dhIuUkkeBMGP/xFjXkvrxwH2ERpSFXjEbz+BoRw== X-Gm-Gg: AeBDieuPuSr4rzD0IsyynX0hnm0+Y/EdbDWKavxzmPupYi6RGSUF01+tiRVij+KNX+R HNX8D/FiYkc8EjBhBkyH7uhGkqXKPQg1PfOCK41JczQt936EI2se8qHzCzKSlD59Q5/Wdx/VU7o jR+jmVnlSXxBUTh3TkhYYJ5DBycl+IyC4IWSYLZIfF17IvSEl5cob8lcGlBC893XxRFw4MAoJSU Ym9QjAhZfej7FT9/BhQJtq8rxhT8vI0NL4h2Anxa1NhmPr1CyH0sl0oVk+C24xbJXrGod2H39xW +4qNUtThVfoxPbHfokO7PL0ZFY9Ousa9wbdR7rdXWWItqB7IkEqRM4GpiiTkx1Qsuk88t/9Efor WqkB/ASxe5eOSapZxyH6DOd/4dCQ= X-Received: by 2002:a05:600c:8b33:b0:485:3fa9:358c with SMTP id 5b1f17b1804b1-488997b2291mr281305855e9.17.1775584304601; Tue, 07 Apr 2026 10:51:44 -0700 (PDT) X-Received: by 2002:a05:600c:8b33:b0:485:3fa9:358c with SMTP id 5b1f17b1804b1-488997b2291mr281305385e9.17.1775584304093; Tue, 07 Apr 2026 10:51:44 -0700 (PDT) Received: from [192.168.188.22] ([80.243.52.133]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488c524fecasm7710255e9.1.2026.04.07.10.51.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Apr 2026 10:51:43 -0700 (PDT) Message-ID: Date: Tue, 7 Apr 2026 19:51:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] SELinux: Dontaudit access to dri devices To: Stefano Brivio , Johannes Segitz References: <20260330110557.2569119-1-jsegitz@suse.de> <20260330171541.15a8b5d0@elisabeth> <20260331214758.227f3fac@elisabeth> <3b5af0d8-1f88-4190-b4ac-5bab780b2781@redhat.com> <243f48b3-ccfa-437f-ac46-9229519b206b@redhat.com> <20260407111110.4153e21b@elisabeth> From: Paul Holzinger In-Reply-To: <20260407111110.4153e21b@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 64HyTEh07stsuws7q032_NZAdCELFOD7aiIz56fcDh8_1775584305 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: XLADFCZJRE6UMZII7VNIBPGQJRNLIXAN X-Message-ID-Hash: XLADFCZJRE6UMZII7VNIBPGQJRNLIXAN X-MailFrom: pholzing@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: passt-dev@passt.top 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 07/04/2026 11:11, Stefano Brivio wrote: > On Tue, 7 Apr 2026 10:27:04 +0200 > Johannes Segitz wrote: > >> On Thu, Apr 02, 2026 at 03:36:58PM +0200, Paul Holzinger wrote: >>> I did a quick spot check in Podman and found a few places where a fd might >>> be leaked: https://github.com/containers/podman/pull/28434 >>> >>> That said I do not think any of these would explain an open /dev/dri path. >> I build podman with the change (and passt with the broader fd closing >> logic) and asked the reporter to test them. The denial is still shown with >> this unfortunately > Johannes, thanks for reporting back. > > Paul, I was wondering: would there be a way to do something equivalent > to that close_range() directly in Podman, before it starts pasta? I > think it's a separate thread (or even a forked process) starting it, > but I haven't really checked. So this is the problem, because the golang runtime manages its own epoll fds. It is not safe to close all fds within go code. We have some work around, custom c init code which counts the fds before the go runtime kicks in but it is kinda fragile and the bigger issue is that we have many commands that may need access to leaked fds, i.e.: - podman run --preserve-fds - systemd socket activition - shell expansion via `<(<<<"somestring")` passes us a string such as "/dev/fd/63", useful to inline a string on a command which only reads a file. It is basically impossible to correctly figure this all out on the podman side without breaking certain use cases. The other issue is that in theory yes lets just close all fds after fork() and before calling exec() but again the go runtime does not allow us to simply fork/exec. Due its nature we are limited to just an exec API with little control over the steps between a fork() (well clone() actually) and exec(). There are ways to pass down fds via that API which the go std code will dup at the right fd numbers but it will by default not close all other fds. Ok, well there is a way using the go std lib, the ExtraFiles array accepts nil entries which means close this fd at this place, i.e. `ExtraFiles = []*os.File{nil,nil}` would result in closing fd 3 and 4. So in order to close all fds we would have to pass a slice with the size of all possible fds on linux which is just not great. And well the go runtime code then calls close() on every single one of them which would just add to much unnecessary overhead for each pasta start. -- Paul Holzinger