On Thu, Jun 21, 2018 at 11:16 PM, Seth Forshee <seth.forshee@xxxxxxxxxxxxx> wrote: [...] >> >> Another argument is that shiftfs itself takes the maximum allowed >> 2 levels of s_stack_depth for it's 2 mounts, so it is actually not >> possible with current VFS limitation to combine shiftfs with overlayfs. > > That's unfortunate -- it will prevent nested use in addition to use with > overlayfs. > > I have been wondering if shiftfs could be made to detect when it was > being layered on top of a shiftfs mount, and do something to make it > behave like it was a single shift on top of the original subtree. I may > look into this. Of course it doesn't help with overlayfs. > Here's a crazy idea for you - after first mount with -o mark, any shiftfs_lookup() will return -EIO, i.e. you start the mount inaccesible to any userns. Then, inside (maybe nested) userns, you allow userns admin to remount -o shift, which resets s_user_ns (allowed only once). Now, any shiftfs operation from the owner userns is allowed and any operation not from owner userns is denied. It may be just a crazy idea and I have no idea how hard it would be to implement, but the upside is that it removes to problem of being able to access the marked and shifted fs at the same time because they simply don't exist at the same time - one transforms into the other in what is hopefully an atomic and secure manner. Note that at no time, should there exist shiftfs dentries nor inodes in cache whose sb->s_user_ns is anything other than the shifted userns (except maybe for the root dentry/inode). Thanks, Amir.
