Alban Crequy <alban@xxxxxxxxxx> writes: > Hi Eric, > > Do you have some cycles for this now that it is the new year? > > A review on the associated ima issue would also be appreciated: > https://www.mail-archive.com/linux-kernel@xxxxxxxxxxxxxxx/msg1587678.html It has taken me longer than I expected but I do have time now. I am moving through these patches and issues a little slowly I do intend to get us through the fuse issues this development cycle if at all possible. I think for starters we should restrict ourselves to the last 4 patches aka (8, 9, 10, 11). In particular we should concentrate on [8/11] fuse: Support fuse filesystems outside of init_user_ns [9/11] fuse: Restrict allow_other to the superblock's namespace or a descendant The tricky issues are handled in the vfs, and I think the remaining tricky issues are evm and ima. Which are close enough to be resolved that we can count them as resolved. Once we have 8 & 9 reviewed and merged we can double check there isn't some silly reason not to set FS_USERNS_MOUNT on fuse and then enable it. I would like to double check and ensure there are not silly issues with posix acls or anything else in the vfs. But I think except for a silly oversight we are good. I should probably also add a patch that adds to Documentation/filesystems that explains what the vfs does for unprivileged mounts. So that I can point people working on filesystems and are thinking about enabling user namespace mounts at the documentation for what the vfs does. That would also provide a good checklist to ensure the way the vfs handles things is sufficient for fuse. As for the earlier patches that enable things. Overall they are good. They are slightly dangerous as they enable more code paths to unprivileged users. But mostly I think they are not immediately necessary and as such a distraction to getting this code in. That said once we get the fuse bits reviewed merged I will be more than happy to merge the relaxation of permission checks that we can perform now that s_user_ns exists. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
