From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 0AABD1F8C6 for ; Thu, 29 Jul 2021 08:56:36 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 38D56388E835 for ; Thu, 29 Jul 2021 08:56:35 +0000 (GMT) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050::465:201]) by sourceware.org (Postfix) with ESMTPS id 2DC2F3858023 for ; Thu, 29 Jul 2021 08:56:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2DC2F3858023 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cyphar.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cyphar.com Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4Gb4Bt0LJhzQk1p; Thu, 29 Jul 2021 10:56:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id gPnIpEN9stw8; Thu, 29 Jul 2021 10:56:15 +0200 (CEST) Date: Thu, 29 Jul 2021 18:56:08 +1000 From: Aleksa Sarai To: Szabolcs Nagy Subject: Re: RFC: Disable clone3 for glibc 2.34 Message-ID: <20210729085608.6n6hxithibfsdslj@senku> References: <87eebkf8ph.fsf@oldenburg.str.redhat.com> <87y29sdsui.fsf@oldenburg.str.redhat.com> <20210727092416.layfgqi6auudbpgc@wittgenstein> <20210727094117.jid7shl7futsciih@wittgenstein> <20210727102222.r2hys526mfkpt4xo@senku> <20210727104816.GC14854@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="35ytvm7sgn2trvpp" Content-Disposition: inline In-Reply-To: <20210727104816.GC14854@arm.com> X-Rspamd-Queue-Id: C079318C1 X-Rspamd-UID: 35958a X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Weimer , Christian Brauner , Florian Weimer via Libc-alpha Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" --35ytvm7sgn2trvpp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-07-27, Szabolcs Nagy wrote: > The 07/27/2021 20:22, Aleksa Sarai wrote: > > Yes, runc has had the -ENOSYS fallback behaviour for a few releases now. > >=20 > > The way it works is that any syscall which has a larger syscall number > > than any syscall specified in the filter will get -ENOSYS (this works > > even if libseccomp is outdated). The only way you could get the -EPERM > > behaviour with modern runc is if you write a seccomp profile that had > > rules for newer syscalls (openat2 for instance) but not clone3 -- but > > Docker doesn't do that. (The reason for this slightly convoluted > > behaviour was to make sure that intentional omissions actually give you > > -EPERM.) >=20 > this sounds broken. it really should return ENOSYS unless > a user specifically asked for a different errno value for > a syscall. EPERM is just wrong. Yes, if I was designing it from scratch, that's what I would've done. But there are already existing filters that are written assuming the default errno is EPERM. Returning ENOSYS from clone(2) or unshare(2) for existing profiles is not a workable solution. Should we fix all existing profiles and then change the behaviour again? Sure, but given we solved this problem in a period of time when people were screaming about glibc being broken in containers, I hope you'll excuse the fact that we didn't really have time to co-ordinate updating every downstream runc user. > we will see random breakage in the future depending on > what unrelated but newer syscalls users added to their > whitelist. who thought this was a good idea? If you update your syscall profile without knowing what you're doing, things will break. That will always be the case. The plan is/was to eventually implement this by explicitly stating a minimum kernel version (so that all syscalls missing in the profile that were available in that kernel version get ENOSYS) but libseccomp doesn't provide that information at the moment, and given that such a filter would be more complicated than the one we have at the moment, that behaviour probably belongs in libseccomp (there are several issues open in the libseccomp repo describing this issue and possible solutions). --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --35ytvm7sgn2trvpp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCYQJtJQAKCRCdlLljIbnQ ElmyAQDJm6cIIYSB5hhSa59K9JkpL87aEtb/RhEk+l3wpW+ewwEAtJjWXRN/d9YZ unpLu/lV0Uex7UpQm1ld53QXviwQygE= =oV1x -----END PGP SIGNATURE----- --35ytvm7sgn2trvpp--