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 :) 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 > _______________________________________________ > Containers mailing list > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linuxfoundation.org/mailman/listinfo/containers >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
