On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote: > On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote: > > Project id's are not exactly "subtree" semantic, but inheritance > > semantics, > > which is not the same when non empty directories get their project > > id changed. > > Here is a recap: > > https://lwn.net/Articles/623835/ > > Yes - but if we abuse them for containers we could refine the > semantics to simply not allow change of project ids from inside > containers based on say capabilities. We can't really abuse projectid, it's part of the user namespace mapping (for project quota). What we can do is have a new id that behaves like it. But like I said, we don't really need a ful ID, it would basically just be a single bit mark to say remap or not when doing permission checks against this inode. It would follow some of the project id semantics (like inheritance from parent dir) > > I guess we should define the semantics for the required sub-tree > > marking, before we can talk about solutions. > > Good plan. So I've been thinking about how to do this without subtree marking and yet retain the subtree properties similar to project id. The advantage would be that if it can be done using only inode properties, then none of the permission prototypes need change. The only real subtree property we need is ability to bind into an unprivileged mount namespace, but we already have that. The gotcha about marking inodes is that they're all or nothing, so every subtree that gets access to the inode inherits the mark. This means that we cannot allow a user access to a marked inode without the cover of an unprivileged user namespace, but I think that's fixable in the permission check (basically if the inode is marked you *only* get access if you have a user_ns != init_user_ns and we do the permission shifts or you have user_ns == init_user_ns and you are admin capable). James
