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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
