Re: Regression in 5.3 for some FS_USERNS_MOUNT (aka user-namespace-mountable) filesystems
From: Al Viro <viro@zeniv.linux.org.uk>
Date: 2019-07-27 02:28:35
Also in:
linux-fsdevel, lkml
Possibly related (same subject, not in this thread)
- 2019-07-27 · Re: Regression in 5.3 for some FS_USERNS_MOUNT (aka user-namespace-mountable) filesystems · Al Viro <viro@zeniv.linux.org.uk>
- 2019-07-27 · Re: Regression in 5.3 for some FS_USERNS_MOUNT (aka user-namespace-mountable) filesystems · Al Viro <viro@zeniv.linux.org.uk>
- 2019-07-27 · Re: Regression in 5.3 for some FS_USERNS_MOUNT (aka user-namespace-mountable) filesystems · Eric W. Biederman <hidden>
- 2019-07-27 · Re: Regression in 5.3 for some FS_USERNS_MOUNT (aka user-namespace-mountable) filesystems · Al Viro <viro@zeniv.linux.org.uk>
- 2019-07-26 · Re: Regression in 5.3 for some FS_USERNS_MOUNT (aka user-namespace-mountable) filesystems · Al Viro <viro@zeniv.linux.org.uk>
On Fri, Jul 26, 2019 at 07:46:18PM -0500, Eric W. Biederman wrote:
If someone had bothered to actually look at how I was proposing to clean things up before the new mount api we would already have that. Sigh. You should be able to get away with something like this which moves the checks earlier and makes things clearer. My old patch against the pre new mount api code.
Check your instances of ->permission(); AFAICS in all cases it's (in current terms) return ns_capable(fc->user_ns, CAP_SYS_ADMIN) ? 0 : -EPERM; In principle I like killing FS_USERNS_MOUNT flag, but when a method is always either NULL or exact same function...