Mickaël Salaün <mic@xxxxxxxxxxx> writes: > Hi, > > I have been looking for this kind of feature for StemJail [1]. One of > the main idea is to being able to create mount points inside a jail as > an unprivileged user but to keep as much as possible the same > environment from outside the jail. For now, I can only create a > mapping for the current user, so when a process list any files > belonging to another user/group it get "nobody", which seems weird > from a user point of view :) Weird but I have never found it harmful. The big thrashing about with adding s_user_ns is complete in my tree so I can accept a reasonable patch, and transparent user namespaces is on the edge. If transparent user namespaces solve anything except for weird. They are simple enough that given a good quality patch I will merge them. Still I want to make certain they solve something real or else I am not certain the added complexity is worth the maintenance burden. Especially in a part of the code where getting confused and making small mistakes results in security issues. On the flip side it isn't that much weirder than from_kuid_munged today so it may not be any kind of problem at all. > > Regards, > Mickaël > > > 1. https://github.com/stemjail/stemjail > > > On 27/06/2016 17:09, Eric W. Biederman wrote: >> >> Added a few more relevant cc's. >> >> Jann Horn <jannh@xxxxxxxxxx> writes: >> >>> This allows the admin of a user namespace to mark the namespace as >>> transparent. All other namespaces, by default, are opaque. >> >> >> I have just skimmed through this and at a high level this doesn't seem >> too scary. Having an identity mapped user namespace that just limits >> you to using a subset of uids and gids while allowing displaying the >> full range of uids and gids. >> >> I don't quite get the use case and I would like to a little better >> but in the long term this shouldn't cause any significant maintenance >> issues, so I don't have any objects. >> >> At the same time this isn't quite the time to merge this. I am in the >> process of slowly going through Seth's vfs changes to support things >> such as truly unprivileged fuse support. Those changes alter which >> places can always be assumed to be init_user_ns (many fewer), and also >> slightly change the set of from_kuid calls being made. >> >> The changes that have made it through my review currently reside at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-next >> >> Those vfs changes make it conceivable and simple from an infrastructure >> standpoint to transition fileystems to unprivileged user namespace >> mounts, with perhaps as little work as just setting FS_USER_NS. At the >> same time that won't be recommend because of the difficulty verifying >> evil filesystem contents can't cause fs implementations to do bad things >> is difficult. >> >> That change means your first patch that just zaps all from_kuid_munged >> users in init_user_ns isn't a particularly good idea. I don't think it >> is a good idea to have one set of rules for things that will always be >> init_user_ns and another set of rules for code that will change. >> >> The long and short of this is I am asking you to wait a week or so and >> rebase this on my for-next branch so that we can confirm this change >> interacts nicely will all of the other on-going work. >> >> Thank you, >> Eric Biederman Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
