Re: [PATCH v5 00/11] FUSE mounts from non-init user namespaces
From: Eric W. Biederman
Date: Mon Feb 19 2018 - 18:10:25 EST
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