From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none 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=fa46NLPt; 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 ESMTP id CA4485A061C for ; Thu, 07 Nov 2024 08:03:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1730963018; 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=jYaYi5LdrzoFXNF7rinMxitq3PntHX4ZbdUhBRzmY5U=; b=fa46NLPtufdcw/u1J70g/iEp8Isa84EuJKKJwoaA+ssUei9qKGOn7bkoujaTcbcJnGlNbM tB1Nx4nMNshXOnkE5jR1q04NVf+nxV/Nv9szOOgnnEsZTETXLdtvhe4AY1DcVGV9VxwJT2 Gm/E6ruty5iiGpqBmgCm/AZQJQLcB4s= 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-204-dY52HzOoOWuiFt6AnJmeCg-1; Thu, 07 Nov 2024 02:03:37 -0500 X-MC-Unique: dY52HzOoOWuiFt6AnJmeCg-1 X-Mimecast-MFC-AGG-ID: dY52HzOoOWuiFt6AnJmeCg Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-43154a0886bso4466765e9.0 for ; Wed, 06 Nov 2024 23:03:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730963015; x=1731567815; 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=jYaYi5LdrzoFXNF7rinMxitq3PntHX4ZbdUhBRzmY5U=; b=k85upWzqoIbYaeW/DEcxpKCQX4x+4oYqSgcqvoQG3EvpYeSkGUC9levk4rzXNiez/T XuCongtlZVtx1NE3n7hVKirtCck1vwtg+vKLJfOKdSoUnryF2r5esbh5FC7UW0PYKz5z gmw8eHA9qolgLMnaMhTqQemdvElbs9GowkQL+rnd0pyQ/loYFeXAB1ZFucs/A4WnfnqX X1YCCBAxeYcjU1pzOYBkp4a/yLY8vREPco+t/cFZvFcVkgVlD4zYSDFiNTEldqqEONtH lT0ofMwM6NAsYjqLzp3KnFfMZUSM0twhnPKETV4mRlgw5PQnm09UtBQejAdS1w8+lzvN aXZQ== X-Gm-Message-State: AOJu0YzcxzV5mcETX8x5CUoJQ2tHWMUDaSM9yqNMnbKAQ3cJPtWlbGi/ lYZFljX6CuN4NoVCs98SN7Kjbj5JBGT12i7Om+8DkkmpxqnhomcodnwXdvZ3ai90rUKABZTAvjz ZA2mMNoSBFmIgovcZLlu67IJqgidd5b+TibsksXzFnN6g8stSQACWASyVkA== X-Received: by 2002:a05:600c:3c83:b0:430:5846:7582 with SMTP id 5b1f17b1804b1-43283242ae4mr168798605e9.7.1730963015269; Wed, 06 Nov 2024 23:03:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IF48RnpqE0smrXmeQXtHsfKxbTqmW/UqDbIjzDW9xsutJTLivCCdv2n95lYkMgSQqp9v2R5Vg== X-Received: by 2002:a05:600c:3c83:b0:430:5846:7582 with SMTP id 5b1f17b1804b1-43283242ae4mr168798345e9.7.1730963014834; Wed, 06 Nov 2024 23:03:34 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-432b0530599sm12572945e9.1.2024.11.06.23.03.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Nov 2024 23:03:32 -0800 (PST) Date: Thu, 7 Nov 2024 08:03:31 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 4/8] linux_dep: Fix CLOSE_RANGE_UNSHARE availability handling Message-ID: <20241107080331.57d8e114@elisabeth> In-Reply-To: References: <20241106065421.2568179-1-david@gibson.dropbear.id.au> <20241106065421.2568179-5-david@gibson.dropbear.id.au> <20241106201223.7e45f87d@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: s1beGZzHGyGZekK82Z1B64b86gWKjB-nWsoSILKE7TM_1730963016 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: DOJVD27M6KQQSCMGV6GTLY3K46TFEXQQ X-Message-ID-Hash: DOJVD27M6KQQSCMGV6GTLY3K46TFEXQQ 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: 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 Thu, 7 Nov 2024 08:01:11 +1100 David Gibson wrote: > On Wed, Nov 06, 2024 at 08:12:23PM +0100, Stefano Brivio wrote: > > On Wed, 6 Nov 2024 17:54:17 +1100 > > David Gibson wrote: > > > > > If CLOSE_RANGE_UNSHARE isn't defined, we define a fallback version of > > > close_range() which is a (successful) no-op. This is broken in several > > > ways: > > > * It doesn't actually fix compile if using old kernel headers, because > > > the caller of close_range() still directly uses CLOSE_RANGE_UNSHARE > > > unprotected by ifdefs > > > > For users using distribution packages, that is, pretty much everybody > > not developing passt, this is generally not a concern, because build > > environments typically ship kernel headers matching the C library and > > the distribution version at hand. > > Unlike some of the other things fixed recently, this one is not > related to compile time versus runtime checks. This one is simply > broken compiling against an older kernel, regardless of the runtime > version. Without this patch, close_open_files() directly uses > CLOSE_RANGE_UNSHARE unprotected by an #ifdef. Ah, right, it's a different case, indeed. > > > * Even if it did fix the compile, it means inconsistent behaviour between > > > a compile time failure to find the value (we silently don't close files) > > > and a runtime failure (we die with an error from close_range()) > > > > Given that this is mostly relevant for stuff built against musl (and > > running on a musl-based distribution), that's not really a problem in > > practice. See 6e9ecf57410b ("util: Provide own version of close_range(), > > and no-op fallback"). > > > > But sure, I'm fine with these changes in general, as they're strictly > > speaking more correct than the current behaviour, minus the next point. > > > > > * Silently not closing the files we intend to close for security reasons > > > is probably not a good idea in any case > > > > It's arguably even worse to force users to run containers or guests as > > root. That's the reason for the no-op implementation. > > Uh... what's the connection to running as root? That you can't run pasta or passt altogether, and if you need some features they provide, not covered by libslirp, you might as well need to switch to run things as root. > > I don't think that introducing a dependency on a >= 5.9 kernel is a > > good idea. > > We already have a dependency on compiling against a >= 5.9 kernel, see > above. Yes, but that would be a trivial fix. > > If this bothers you or cppcheck, I'd rather call close_range() > > (possibly the weakly aliased implementation), and log a warning on > > ENOSYS instead of failing. > > We could do that. We'd need to consider EINVAL as well as ENOSYS, for > the case that the syscall exists, but the CLOSE_RANGE_UNSHARE flag > isn't recognized. Right... I think we should do that. -- Stefano