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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 AF03CC34056 for ; Wed, 19 Feb 2020 17:19:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 61FFA20801 for ; Wed, 19 Feb 2020 17:19:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582132746; bh=pdkNY2hNSnY9gfk2NzrHjgF6xJM4H9Y/ewvIWmreT30=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=sLYwoSzFyxH0zDCericBVAJgCjQYcx2evrrjE0pztqf7UItmbJlCOncgZc4gzkID+ 3Tva69Z3jJ5dyFKaeh63ulEo+1agS2alTBaHZyhnFjqp331RrJDctM/PvSkpihfsNc WaHP9ihvlOQMNxB/Thkbgybr4wfwMMuXKZYaohLM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726750AbgBSRTF (ORCPT ); Wed, 19 Feb 2020 12:19:05 -0500 Received: from mail.kernel.org ([198.145.29.99]:42744 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726518AbgBSRTE (ORCPT ); Wed, 19 Feb 2020 12:19:04 -0500 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1BB072465D for ; Wed, 19 Feb 2020 17:19:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582132744; bh=pdkNY2hNSnY9gfk2NzrHjgF6xJM4H9Y/ewvIWmreT30=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=vnO2O4ARZ57+m2WKOUb7GhddjqaoDXVsuMXfiNZeEGx2CUEhSrcOLwk7vQ6jehuVY 7ZAQf5jzJfdbS7ByhaI5MGieQG5Akj0KliXYRwXHNlnQNEhGb87pr//Tw8tqFq6uyH kyfrK/detgBoqWdOmwxa2BWw5+K7YNOlQZ/t1UXw= Received: by mail-wm1-f44.google.com with SMTP id c84so1514522wme.4 for ; Wed, 19 Feb 2020 09:19:04 -0800 (PST) X-Gm-Message-State: APjAAAX8loCQ14oE7f8nDpoHtcUhdqFv03xMT2dHFAJAqIatPlEvSJx/ FZKrd7XDyE/HWxicn0d1pQXh/moFzH1fk2Z6rDLxlQ== X-Google-Smtp-Source: APXvYqzBqeT3cBwt5QLq0QxxbNo0Ff+khHeTRw3LvaqWbB7JAMELbBnkX4mD5JEjB+jVyyVW16JjTf+gEg/eDtdINSk= X-Received: by 2002:a1c:b0c3:: with SMTP id z186mr10898715wme.36.1582132742597; Wed, 19 Feb 2020 09:19:02 -0800 (PST) MIME-Version: 1.0 References: <20200218143411.2389182-1-christian.brauner@ubuntu.com> <20200218143411.2389182-10-christian.brauner@ubuntu.com> <20200219024233.GA19334@mail.hallyn.com> <20200219120604.vqudwaeppebvisco@wittgenstein> In-Reply-To: <20200219120604.vqudwaeppebvisco@wittgenstein> From: Andy Lutomirski Date: Wed, 19 Feb 2020 09:18:51 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 09/25] fs: add is_userns_visible() helper To: Christian Brauner Cc: "Serge E. Hallyn" , =?UTF-8?Q?St=C3=A9phane_Graber?= , "Eric W. Biederman" , Aleksa Sarai , Jann Horn , smbarber@chromium.org, Seth Forshee , Alexander Viro , Alexey Dobriyan , James Morris , Kees Cook , Jonathan Corbet , Phil Estes , LKML , Linux FS Devel , Linux Containers , LSM List , Linux API Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 19, 2020 at 4:06 AM Christian Brauner wrote: > > On Tue, Feb 18, 2020 at 08:42:33PM -0600, Serge Hallyn wrote: > > On Tue, Feb 18, 2020 at 03:33:55PM +0100, Christian Brauner wrote: > > > Introduce a helper which makes it possible to detect fileystems whose > > > superblock is visible in multiple user namespace. This currently only > > > means proc and sys. Such filesystems usually have special semantics so their > > > behavior will not be changed with the introduction of fsid mappings. > > > > Hi, > > > > I'm afraid I've got a bit of a hangup about the terminology here. I > > *think* what you mean is that SB_I_USERNS_VISIBLE is an fs whose uids are > > always translated per the id mappings, not fsid mappings. But when I see > > Correct! > > > the name it seems to imply that !SB_I_USERNS_VISIBLE filesystems can't > > be seen by other namespaces at all. > > > > Am I right in my first interpretation? If so, can we talk about the > > naming? > > Yep, your first interpretation is right. What about: wants_idmaps() Maybe fsidmap_exempt()? I still haven't convinced myself that any of the above is actually correct behavior, especially when people do things like creating setuid binaries.