From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [PATCH review 0/11] General unprivileged mount support Date: Wed, 06 Jul 2016 10:19:04 -0500 Message-ID: <87vb0ilrpz.fsf@x220.int.ebiederm.org> References: <87ziq03qnj.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: (Andy Lutomirski's message of "Wed, 6 Jul 2016 07:01:39 -0700") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Andy Lutomirski Cc: Jan Kara , Jann Horn , Linux API , Linux Containers , James Bottomley , Seth Forshee , Michael Kerrisk , Linux FS Devel , Djalal Harouni List-Id: containers.vger.kernel.org Andy Lutomirski writes: > On Sat, Jul 2, 2016 at 10:18 AM, Eric W. Biederman > wrote: >> >> As well as in these patches the code is also available from: >> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-testing >> >> It has been a long time in coming but recently in the userns tree the >> superblock has been expanded with a s_user_ns field indicating the user >> namespace that owns a superblock. >> > > It would be nice if global root could mount otherwise-unsafe > filesystems with s_user_ns set to a non-init namespace. Do you have > plans to allow that? Looking at the code global root would pass the permission checks that are present in my tree today. At the same time I don't have a provision for global root to specify the user namespace. The practical limitation is that the filesystems need a little bit of gentle massaging to handle the case when s_user_ns != &init_user_ns. I think i_uid_read and i_uid_write already provide 90% of that. The other limitation is that s_user_ns is defined as the owner of the filesystem and as the default translation. Which will mean root in s_user_ns will be trusted to remount the filesystem. The primary target right now is a safe unprivileged mount of fuse. I am not opposed to extensions allowing the global root to mount otherwise-unsafe filesystems with s_user_ns != &init_user_ns as long as it is for cases where we can trust the underlying filesystem image and don't mind giving root in s_user_ns all interesting permissions over the filesystem. I think that could be an very interesting intermediary step in getting filesystems supported. Still my focus is true unprivileged mounts, there are a huge number of little details that go into getting that right, and my poor brain can't handle looking at cases beyond that. Eric