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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 1522EC4363A for ; Thu, 29 Oct 2020 16:57:37 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0CBC020747 for ; Thu, 29 Oct 2020 16:57:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0CBC020747 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hallyn.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=linux-audit-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-521-pM6DjIJ2OdWmXkEwn7pP2A-1; Thu, 29 Oct 2020 12:57:32 -0400 X-MC-Unique: pM6DjIJ2OdWmXkEwn7pP2A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 838F664150; Thu, 29 Oct 2020 16:57:28 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4E4CC5C3E0; Thu, 29 Oct 2020 16:57:28 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id BFB781800BB2; Thu, 29 Oct 2020 16:57:27 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 09TGU5Zg000838 for ; Thu, 29 Oct 2020 12:30:05 -0400 Received: by smtp.corp.redhat.com (Postfix) id 39BA8EB35C; Thu, 29 Oct 2020 16:30:05 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 34001EC4AF for ; Thu, 29 Oct 2020 16:30:03 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CFD91185A7A1 for ; Thu, 29 Oct 2020 16:30:02 +0000 (UTC) Received: from mail.hallyn.com (mail.hallyn.com [178.63.66.53]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-328-DrzGrvtaMeSznx12AKgiYw-1; Thu, 29 Oct 2020 12:29:57 -0400 X-MC-Unique: DrzGrvtaMeSznx12AKgiYw-1 Received: by mail.hallyn.com (Postfix, from userid 1001) id C24CF11F1; Thu, 29 Oct 2020 11:23:17 -0500 (CDT) Date: Thu, 29 Oct 2020 11:23:17 -0500 From: "Serge E. Hallyn" To: Tycho Andersen Subject: Re: [PATCH 00/34] fs: idmapped mounts Message-ID: <20201029162317.GA12461@mail.hallyn.com> References: <20201029003252.2128653-1-christian.brauner@ubuntu.com> <87pn51ghju.fsf@x220.int.ebiederm.org> <20201029161231.GA108315@cisco> MIME-Version: 1.0 In-Reply-To: <20201029161231.GA108315@cisco> User-Agent: Mutt/1.9.4 (2018-02-28) X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-loop: linux-audit@redhat.com X-Mailman-Approved-At: Thu, 29 Oct 2020 12:57:25 -0400 Cc: Andy Lutomirski , Mimi Zohar , David Howells , Andreas Dilger , Miklos Szeredi , smbarber@chromium.org, Christoph Hellwig , Alban Crequy , linux-ext4@vger.kernel.org, Mrunal Patel , Arnd Bergmann , Jann Horn , selinux@vger.kernel.org, Josh Triplett , Seth Forshee , Alexander Viro , Lennart Poettering , OGAWA Hirofumi , Geoffrey Thomas , James Bottomley , John Johansen , Theodore Tso , Dmitry Kasatkin , containers@lists.linux-foundation.org, Jonathan Corbet , linux-unionfs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-audit@redhat.com, "Eric W. Biederman" , linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, Todd Kjos X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Oct 29, 2020 at 10:12:31AM -0600, Tycho Andersen wrote: > Hi Eric, > > On Thu, Oct 29, 2020 at 10:47:49AM -0500, Eric W. Biederman wrote: > > Christian Brauner writes: > > > > > Hey everyone, > > > > > > I vanished for a little while to focus on this work here so sorry for > > > not being available by mail for a while. > > > > > > Since quite a long time we have issues with sharing mounts between > > > multiple unprivileged containers with different id mappings, sharing a > > > rootfs between multiple containers with different id mappings, and also > > > sharing regular directories and filesystems between users with different > > > uids and gids. The latter use-cases have become even more important with > > > the availability and adoption of systemd-homed (cf. [1]) to implement > > > portable home directories. > > > > Can you walk us through the motivating use case? > > > > As of this year's LPC I had the distinct impression that the primary use > > case for such a feature was due to the RLIMIT_NPROC problem where two > > containers with the same users still wanted different uid mappings to > > the disk because the users were conflicting with each other because of > > the per user rlimits. > > > > Fixing rlimits is straight forward to implement, and easier to manage > > for implementations and administrators. > > Our use case is to have the same directory exposed to several > different containers which each have disjoint ID mappings. > > > Reading up on systemd-homed it appears to be a way to have encrypted > > home directories. Those home directories can either be encrypted at the > > fs or at the block level. Those home directories appear to have the > > goal of being luggable between systems. If the systems in question > > don't have common administration of uids and gids after lugging your > > encrypted home directory to another system chowning the files is > > required. > > > > Is that the use case you are looking at removing the need for > > systemd-homed to avoid chowning after lugging encrypted home directories > > from one system to another? Why would it be desirable to avoid the > > chown? > > Not just systemd-homed, but LXD has to do this, as does our > application at Cisco, and presumably others. > > Several reasons: > > * the chown is slow > * the chown requires somewhere to write the delta in metadata (e.g. an > overlay workdir, or an LV or something), and there are N copies of > this delta, one for each container. > * it means we need to have a +w filesystem at some point during > execution. > * it's ugly :). Conceptually, the kernel solves the uid shifting > problem for us for most other kernel subsystems (including in a > limited way fscaps) by configuring a user namespace. It feels like > we should be able to do the same with the VFS. And chown prevents the same inode from being shared by different containers through different id mappings. You can overlay, but then they can't actually share updates. -serge -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit