From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0596EC43334 for ; Wed, 15 Jun 2022 08:14:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8C31D6B0074; Wed, 15 Jun 2022 04:14:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8730B6B0075; Wed, 15 Jun 2022 04:14:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 762166B0078; Wed, 15 Jun 2022 04:14:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 677A66B0074 for ; Wed, 15 Jun 2022 04:14:28 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3C608603AD for ; Wed, 15 Jun 2022 08:14:28 +0000 (UTC) X-FDA: 79579758216.20.73DD051 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 74F7380094 for ; Wed, 15 Jun 2022 08:14:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655280867; 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: in-reply-to:in-reply-to:references:references; bh=YJSmIjchRt0MiM65IzYG4GVOYlEijEmaflQlPrsPyMM=; b=PPAmiMRy3dE1IlRhVUn08dkzybTdfTo3k82Xg+s9ISGgRI3g720+DL9DPxhFiuuoaXcIWg TJfSxcmpHz7TdyakUTaluKdEzyN30tT78xKiXS4A4i5oK0wLq6w3vfKN83rxI/RJLPjWE6 K+ZB2huy0eSn60HKgHqgT/uc4KKspD4= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-191-QGzFYCVkM9mCn86h-ASu1g-1; Wed, 15 Jun 2022 04:14:22 -0400 X-MC-Unique: QGzFYCVkM9mCn86h-ASu1g-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 52AC93802B91; Wed, 15 Jun 2022 08:14:22 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.90]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D9380492CA5; Wed, 15 Jun 2022 08:14:20 +0000 (UTC) From: Florian Weimer To: Christian Brauner Cc: Kees Cook , Andrei Vagin , linux-kernel@vger.kernel.org, Dmitry Safonov <0x7f454c46@gmail.com>, linux-mm@kvack.org, Eric Biederman Subject: Re: [PATCH 1/2] fs/exec: allow to unshare a time namespace on vfork+exec References: <20220613060723.197407-1-avagin@gmail.com> <202206141412.2B0732FF6C@keescook> <874k0mqs5i.fsf@oldenburg.str.redhat.com> <20220615080000.qtxeosohhyfabzmg@wittgenstein> Date: Wed, 15 Jun 2022 10:14:19 +0200 In-Reply-To: <20220615080000.qtxeosohhyfabzmg@wittgenstein> (Christian Brauner's message of "Wed, 15 Jun 2022 10:00:00 +0200") Message-ID: <87zgiepcmc.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655280867; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YJSmIjchRt0MiM65IzYG4GVOYlEijEmaflQlPrsPyMM=; b=sPuKdhbQs3fge8BMc278rG2gl8P7TXOLXHzUsb9X8PHXmt9MTKIuOjD6pIsfLT3KZ7BvZa AAvhk2CzvmU2yvCGoF3J0/QZabhMihGg+abuG1sus//eWygM+MHk7SQp9Uun3XLP0js4hX kYZd/Lh2SlwyZ1LH5R2iXM0NQoK1wpY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PPAmiMRy; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf02.hostedemail.com: domain of fweimer@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=fweimer@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655280867; a=rsa-sha256; cv=none; b=ihiD161x66M9UPodOY5NmN/wwXtge5C+1YKo3BC5+HSD6rdArInvhWzICjc/aRrwsNZK+Q j6V0J5bzm+L6Exoiknxoz6Xsq9tRACr8uopvcDAq3QDvFqUWnfMyywhWDja6wvI/xtpKfv RtZeun8ENHYWCI3jpEayG4p2qvs5xBo= X-Stat-Signature: 6bno68qb7d43a5s39t9kkkjm6xx8dibo X-Rspamd-Queue-Id: 74F7380094 X-Rspam-User: X-Rspamd-Server: rspam05 Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PPAmiMRy; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf02.hostedemail.com: domain of fweimer@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=fweimer@redhat.com X-HE-Tag: 1655280867-488162 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: * Christian Brauner: > For pid namespaces one problem would be that it could end up confusing a > process about its own pid. This was a more serious problem when the pid > cache was still active in glibc; but fwiw systemd still has a pid cache > afair. Right. glibc still has a TID cache, mainly for use with recursive mutexes (where we need a 32-bit thread identifier and can't perform a system call on every locking operation for performance reasons). Assuming that a non-delayed CLONE_NEWPID would also change the TID underneath us, we'd have subtly broken recursive mutexes. vfork gets away with not updating the TID cache (which is shared with the parent process) because the parent process is suspended while the new subprocess is still running and has not execve'ed yet. Now one could argue that calling unshare automatically means that you must not call any glibc functions afterwards (similar to thread-creating clone), or at least that you cannot call any functions which are not async-signal-safe, but that does not match existing application practice. And I think we actually prefer that file servers call chroot after unshare(CLONE_FS), rather than trying to reimplement restricted pathname lookup in userspace. Thanks, Florian