lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 29 Oct 2020 10:47:49 -0500 From: ebiederm@...ssion.com (Eric W. Biederman) To: Christian Brauner <christian.brauner@...ntu.com> Cc: Alexander Viro <viro@...iv.linux.org.uk>, Christoph Hellwig <hch@...radead.org>, linux-fsdevel@...r.kernel.org, John Johansen <john.johansen@...onical.com>, James Morris <jmorris@...ei.org>, Mimi Zohar <zohar@...ux.ibm.com>, Dmitry Kasatkin <dmitry.kasatkin@...il.com>, Stephen Smalley <stephen.smalley.work@...il.com>, Casey Schaufler <casey@...aufler-ca.com>, Arnd Bergmann <arnd@...db.de>, Andreas Dilger <adilger.kernel@...ger.ca>, OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>, Geoffrey Thomas <geofft@...reload.com>, Mrunal Patel <mpatel@...hat.com>, Josh Triplett <josh@...htriplett.org>, Andy Lutomirski <luto@...nel.org>, Amir Goldstein <amir73il@...il.com>, Miklos Szeredi <miklos@...redi.hu>, Theodore Tso <tytso@....edu>, Alban Crequy <alban@...volk.io>, Tycho Andersen <tycho@...ho.ws>, David Howells <dhowells@...hat.com>, James Bottomley <James.Bottomley@...senpartnership.com>, Jann Horn <jannh@...gle.com>, Seth Forshee <seth.forshee@...onical.com>, Stéphane Graber <stgraber@...ntu.com>, Aleksa Sarai <cyphar@...har.com>, Lennart Poettering <lennart@...ttering.net>, smbarber@...omium.org, Phil Estes <estesp@...il.com>, Serge Hallyn <serge@...lyn.com>, Kees Cook <keescook@...omium.org>, Todd Kjos <tkjos@...gle.com>, Jonathan Corbet <corbet@....net>, containers@...ts.linux-foundation.org, linux-security-module@...r.kernel.org, linux-api@...r.kernel.org, linux-ext4@...r.kernel.org, linux-unionfs@...r.kernel.org, linux-audit@...hat.com, linux-integrity@...r.kernel.org, selinux@...r.kernel.org Subject: Re: [PATCH 00/34] fs: idmapped mounts Christian Brauner <christian.brauner@...ntu.com> 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. 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? If the goal is to solve fragmented administration of uid assignment I suggest that it might be better to solve the administration problem so that all of the uids of interest get assigned the same way on all of the systems of interest. To the extent it is possible to solve the uid assignment problem that would seem to have fewer long term administrative problems. Eric
Powered by blists - more mailing lists