linux-kernel - Re: [RFC PATCH 0/0] VFS:userns: support portable root filesystems

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160504163845.GB13196@x>
Date:	Wed, 4 May 2016 09:38:45 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Djalal Harouni <tixxdz@...il.com>
Cc:	Djalal Harouni <tixxdz@...ndz.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Chris Mason <clm@...com>, tytso@....edu,
	Serge Hallyn <serge.hallyn@...onical.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andy Lutomirski <luto@...nel.org>,
	Seth Forshee <seth.forshee@...onical.com>,
	Dongsu Park <dongsu@...ocode.com>,
	David Herrmann <dh.herrmann@...glemail.com>,
	Miklos Szeredi <mszeredi@...hat.com>,
	AlbanCrequy <alban.crequy@...il.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: [RFC PATCH 0/0] VFS:userns: support portable root filesystems

On Wed, May 04, 2016 at 11:08:42AM +0100, Djalal Harouni wrote:
> On Tue, May 03, 2016 at 05:41:07PM -0700, Josh Triplett wrote:
> > The main design constraint with a full mapping would be passing that
> > through "mount".  There have been discussions on and off for years about
> > replacing the mount() system call with something either two-phase (get
> > filesystem driver FD, send it a series of parameters ending with mount;
> > the VFS would interpret many of those parameters) or three-phase (get
> > filesystem driver FD, send it parameters ending with getting a directory
> > FD, bind the directory FD).  Given an interface like that, providing a
> > UID/GID map at mount time seems plausible.
> Could you please provide some links for these discussions ?
> 
> I'll get back to it.

I don't know of a good example of those discussions occurring in public;
they've occurred at Kernel Summit for years.

Al Viro would know if they've been discusssed publically.  Al?

> > Alternatively, a much simpler approach that could potentially be
> > expanded in the future would be to add *two* parameters each for UID and
> > GID: a base and a max.  That would define a range, which doesn't
> > necessarily need to be exactly 2**16; thus, if you had a big enough
> > range, that approach would nest as well.
> Hm, I can see but I'm not sure if it will make sense, since this
> will hardcode the mapping during mount ? where maybe that mount can be
> used later for another mapping configuration ? I think we should just
> get a user namespace reference and that's it. Now we just allow the
> current user namespace interface to do the job for us, and as said above
> the 2**16 is just an example.

Please ignore this last paragraph; it was based on my misunderstanding
the approach you took.

- Josh Triplett