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 X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 759E3C43143 for ; Mon, 1 Oct 2018 16:18:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2EF4F2089A for ; Mon, 1 Oct 2018 16:18:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cyphar-com.20150623.gappssmtp.com header.i=@cyphar-com.20150623.gappssmtp.com header.b="bZ9DsDa/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2EF4F2089A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=cyphar.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726636AbeJAW50 (ORCPT ); Mon, 1 Oct 2018 18:57:26 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:43106 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726367AbeJAW5Z (ORCPT ); Mon, 1 Oct 2018 18:57:25 -0400 Received: by mail-pf1-f196.google.com with SMTP id p24-v6so1070905pff.10 for ; Mon, 01 Oct 2018 09:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cyphar-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=I6GrG+gQD9xKwEFBUogR5ek5OrySfcEy7QQ3sXz5IL8=; b=bZ9DsDa/Za5uwtH+ZegoPWJMgJ71S9PWox2SE+vG6NfcJEAdU1tZwhR/Jkg58NWrl+ AwCFP/eSA9fiRbV6JLGjY7+jzVNngtYM9rOtQdJo4Lmdi3xpxvMYKv4o2sefzRgVDkDc Dv87lqDwPDGOooUQDWjDqaDDHlmzQJP56fbi8Q+4bFBJ9VS29BLGJ6830o17ccKBfAxl khG6phWwDC1dNMFBYNDea29WYMh05vXMyVnG7bZKZrC/YfBAUQ92kDJZlKl4VYcrD/c1 BGkjeXjBlWMCqaoVmoAGX5P3pMpmREn4s4u8C5bgu1lpTQ6ZqF5WQO6bOA8TaHFuP6G8 JNow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=I6GrG+gQD9xKwEFBUogR5ek5OrySfcEy7QQ3sXz5IL8=; b=UHg4PRJ176htULzqXJNOeeNH/FRhI5VLL39TZoJ4vUMMIBXFLC45SXPD+xs/fpqgao U7YmW4kxi3eJqwz0r35Sml4TCupgxsgHJSGTuPMNcruxFBvYAj2yD9bOCtmiY4xIijcp oltVCX4MptdEfxouZtuMk2STHxCY37wS+gYuuvAB4/UV5GWU5QNFA2Zb9Y3AtOayeRsY 014cbRwGJGbSNNbx5feDP+DTpYngOcr2Nj+U73Y6x6gc/QBmOCulw+pwRys/j0A2CH+0 Pcnt+fjAriabpJWX9KMfe3mB6nLq78O8EyjMsk91/PIQHikLofoBAPgiQlmCycouL6jk vSnA== X-Gm-Message-State: ABuFfoiYq8zxIEMAxeMabq6wX060RYB+yXEcbh8fJkC+3xSXDW2+J0Tq qxscpDCYwxQFEn5JhR0bxDzEOQ== X-Google-Smtp-Source: ACcGV60UzybwBzqpFyba+24Zo5UsJa/NGf5Ch8KpA73q5FbWcBT4c1U2slMgBKhoaVLaRb6Sm5+Fyg== X-Received: by 2002:a17:902:6b03:: with SMTP id o3-v6mr12699573plk.333.1538410731660; Mon, 01 Oct 2018 09:18:51 -0700 (PDT) Received: from ryuk ([220.240.25.129]) by smtp.gmail.com with ESMTPSA id i123-v6sm17720213pgd.91.2018.10.01.09.18.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 01 Oct 2018 09:18:50 -0700 (PDT) Date: Tue, 2 Oct 2018 02:18:33 +1000 From: Aleksa Sarai To: Jann Horn Cc: "Eric W. Biederman" , Al Viro , jlayton@kernel.org, Bruce Fields , Arnd Bergmann , shuah@kernel.org, David Howells , Andy Lutomirski , christian@brauner.io, Tycho Andersen , kernel list , linux-fsdevel@vger.kernel.org, linux-arch , linux-kselftest@vger.kernel.org, dev@opencontainers.org, containers@lists.linux-foundation.org, Linux API Subject: Re: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution Message-ID: <20181001161833.sg5iy6gk7n7crcvy@ryuk> References: <20180929103453.12025-1-cyphar@cyphar.com> <20180929131534.24472-1-cyphar@cyphar.com> <20181001054246.gfinmx3api7kjhmc@ryuk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vthx2kfvccrg2h7c" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --vthx2kfvccrg2h7c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2018-10-01, Jann Horn wrote: > > If this is an issue for AT_THIS_ROOT, I believe this might also be an > > issue for AT_BENEATH since they are effectively both using the same > > nd->root trick (so you could similarly trick AT_BENEATH to not error > > out). So we'd need to figure out how to solve this problem in order for > > AT_BENEATH to be safe. >=20 > Oh, wait, what? I think I didn't notice that the semantics of > AT_BENEATH changed like that since the original posting of David > Drysdale's O_BENEATH_ONLY patch > (https://lore.kernel.org/lkml/1439458366-8223-2-git-send-email-drysdale@g= oogle.com/). > David's patch had nice, straightforward semantics, blocking any form > of upwards traversal. Why was that changed? Does anyone actually want > to use paths that contain ".." with AT_BENEATH? I would strongly > prefer something that blocks any use of "..". >=20 > @Al: It looks like this already changed back when you posted > https://lore.kernel.org/lkml/20170429220414.GT29622@ZenIV.linux.org.uk/ > ? Yes, I copied the semantics from Al's patchset. I don't know why he felt strongly that this was the best idea, but in my opinion allowing paths like "a/../b/../c" seems like it's quite useful because otherwise you wouldn't be able to operate on most distribution root filesystems (many have symlinks that have ".." components). Looking at my own (openSUSE) machine there are something like 100k such symlinks (~37% of symlinks on my machine). While I do understand that the easiest way of solving this problem is to disallow ".." entirely with AT_BENEATH, given that support ".." has utility, I would like to know whether it's actually not possible to have this work safely. > > Speaking naively, doesn't it make sense to invalidate the walk if a path > > component was modified? Or is this something that would be far too > > costly with little benefit? What if we do more aggressive nd->root > > checks when resolving with AT_BENEATH or AT_THIS_ROOT (or if nd->root != =3D > > current->mnt_ns->root)? >=20 > It seems to me like doing that would basically require looking at each > node in the path walk twice? And it'd be difficult to guarantee > forward progress unless you're willing to do some fairly heavy > locking. I had another idea since I wrote my previous mail -- since the issue (at least the way I understand it) is that ".." can "skip" over nd->root because of the rename, what if we had some sort of is_descendant() check within follow_dotdot()? (FWIW, ".." already has some pretty interesting "hand-over-hand" locking semantics.) This should be effectively similar to how prepend_path() deals with a path that is not reachable from @root (I'm not sure if the locking is acceptable for the namei path though). Since ".." with AT_THIS_ROOT (or AT_BENEATH) is not going to be the most common component type (and we only need to do these checks for those flags), I would think that the extra cost would not be _that_ awful. Would this work? > > You're right about this -- for C runtimes. In Go we cannot do a raw > > clone() or fork() (if you do it manually with RawSyscall you'll end with > > broken runtime state). So you're forced to do fork+exec (which then > > means that you can't use CLONE_FILES and must use SCM_RIGHTS). Same goes > > for CLONE_VFORK. >=20 > If you insist on implementing every last bit of your code in Go, I guess. Fair enough, though I believe this would affect most multi-threaded programs as well (regardless of the language they're written in). --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --vthx2kfvccrg2h7c Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXzbGxhtUYBJKdfWmnhiqJn3bjbQFAluySNkACgkQnhiqJn3b jbQGrQ/8DfvGXFadKu6bEEYB9Kfrd6a6m3oIhQWRukSMW96NcqgL84kKLP8wcfJY SsRGv9CDyiGZAeW2MHH8T08w7M4P1ysfRVwBlQs+X41r/iRUMoMTVMaBX0VcmUiQ SznLG//7brkKgwDovB2rK9BssUlgGMy1trvF57grMY/C0S6Qf/2eTnAzBtAGbIuI TQ8NQYHx5eXvWpTkyF9gCpeFaEzQKxQAkufMiGazdQea9OxOu9LeE3B6SZZrnAwM mWhqVwfX6jfHYZX/46vzUzebK13z5726nBbO2cFoWuZMHQn7mmuOzWu8+/C+BTao sUq7sDBLhtO4qlCGVRYzSdXRgRX+24v04ar83EluUeRmWbDhDUhcoXpeyCLQb9Ae w6JiH7GupLPzHJ2omat3r48rgnCl15sgB0BshxPo2wZ/HZ2XBUHLg2rW6PX75N9O XFrndHdNAbcO6KCGqWb0+1mUJ0ASG3Pc0JOnkA3SSnvXrS1quaG6Qq515JFBFtiF +kLjWJ9zcRaF5votbcwYcXdwjczbweafx2ra1ICzlhrPDVB0wXQCg7QiPHLHvFk7 s4I8RsjSeoqaI76r13KV+81Zs4po/FGy7HrOWDFr+g2oFQdAefEPKeCDAJ8lZM2R 7GKit9omR6QGkFb6v1DrTuXmreOuMy+2y4Y5BC9Gs4U4pl7469I= =avQm -----END PGP SIGNATURE----- --vthx2kfvccrg2h7c--