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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,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 A0670C3F2CD for ; Fri, 28 Feb 2020 15:40:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 782C1246AE for ; Fri, 28 Feb 2020 15:40:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=szeredi.hu header.i=@szeredi.hu header.b="J8Yk12NM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727225AbgB1PkY (ORCPT ); Fri, 28 Feb 2020 10:40:24 -0500 Received: from mail-io1-f66.google.com ([209.85.166.66]:43099 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726905AbgB1PkW (ORCPT ); Fri, 28 Feb 2020 10:40:22 -0500 Received: by mail-io1-f66.google.com with SMTP id n21so3825311ioo.10 for ; Fri, 28 Feb 2020 07:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9LqrzC6b4MYZRRh7fElw2sFSCD8yqepAp1R1qGOOE9o=; b=J8Yk12NMM3aPoUGzMtUEGaWQFyt3fGjSMbPBBqAHvUe0SiUviOzH6VRNTh7x/BJ7Nk fo5M6inLsbXFrgRv1vvzEFHoaLLfvF0hcPU0nGmaPzvQ0XYHYF3wvsXRgaRhkpjx0NjV kUMeGbbANhNsXkeTJ9LhowDRAkP/N2ybtUnaA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9LqrzC6b4MYZRRh7fElw2sFSCD8yqepAp1R1qGOOE9o=; b=Yv7ZsYTfnkMPAjDabGpejAx7o1+fyi2kxz707pelYLB/5hsUlJQulqh3LXkOJaGaRs +zdtjalPJf5OIns6NIBPHtflz7Z8/wGfvsL9pwDLlyxuwUEyUd0609iVlok6+2TCAumm I6uwkxxO79lguTebV1huElGdgeKVN5jJKUK6Q2JHn1AwPuH4Yf8DuVNNAQ9fnJlGzyNz 9z1ZVZZFRNhYSIh+5ToF1G/TPDsCVj/2ght0yI5Cb9HlHwMgjBNiQnv9kEZiiT1vKdWb 595lu0a6g52o5/v3Sqksve6pMC9ojqQOa2ln/irIAuoIoLwLZcpBCozU1Fell6aMoMw/ /dKQ== X-Gm-Message-State: APjAAAUJvBB1pajgdAzZ0GcyiiiwnBAtURzW41hNQHEgFKt1gxoHEZI3 JikDztznaLTIIDmTWRYYpNVr7/oWCmV9TEftzKSzww== X-Google-Smtp-Source: APXvYqxWaKGs/GMkcpGpUL7E+8RUggAdz5iFOr+Psoqlg5UOSbDYmueoqkK9GE5rgDFb+W9horX9kqWoe/ME2cmp0yI= X-Received: by 2002:a02:6a10:: with SMTP id l16mr3820784jac.77.1582904420636; Fri, 28 Feb 2020 07:40:20 -0800 (PST) MIME-Version: 1.0 References: <1582556135.3384.4.camel@HansenPartnership.com> <1582644535.3361.8.camel@HansenPartnership.com> <1c8db4e2b707f958316941d8edd2073ee7e7b22c.camel@themaw.net> <3e656465c427487e4ea14151b77d391d52cd6bad.camel@themaw.net> <20200227151421.3u74ijhqt6ekbiss@ws.net.home> <1582902521.3338.20.camel@HansenPartnership.com> In-Reply-To: <1582902521.3338.20.camel@HansenPartnership.com> From: Miklos Szeredi Date: Fri, 28 Feb 2020 16:40:09 +0100 Message-ID: Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] To: James Bottomley Cc: Ian Kent , Karel Zak , Miklos Szeredi , Steven Whitehouse , David Howells , viro , Christian Brauner , Jann Horn , "Darrick J. Wong" , Linux API , linux-fsdevel , lkml , Lennart Poettering , =?UTF-8?Q?Zbigniew_J=C4=99drzejewski=2DSzmek?= , Greg Kroah-Hartman , util-linux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Feb 28, 2020 at 4:09 PM James Bottomley wrote: > Containers are file based entities, so file descriptors are their most > natural thing and they have full ACL protection within the container > (can't open the file, can't then get the fd). The other reason > container people like file descriptors (all the Xat system calls that > have been introduced) is that if we do actually need to break the > boundaries or privileges of the container, we can do so by getting the > orchestration system to pass in a fd the interior of the container > wouldn't have access to. Yeah, agreed about the simplicity of fd based access. Then again a filesystem access would allow immediate access to all scripts, languages, etc. That, I think is a huge bonus compared to the ioctl-like mess that the current proposal is, which would require library, utility, language binding updates on all changes. Ugh. One way to resolve that is to have the mount information magic-symlinked from /proc/PID/fdmount/FD directly to the mountinfo dir, which would then have a link into the sbinfo dir. With other access denied to all except sysadmin. Would that work? Thanks, Miklos