Hi Eric,
most filesystems cannot be mounted in a non-init user namespace because we
don't trust the superblock parsers to DTRT when handed garbage. I was
wondering if you had any ideas on ways that allowing root in a non-init userns
to mount an overlayfs fs would be dangerous? There's no superblock parsing in
that case at all; writes end up being allowed if and only if the userid owning
the 'upper' (writeable) layer is mapped into the userns. Near as I can tell
it should be quite safe. But my imagination isn't the most active.
I assume there would be concerns about memory usage if the system is not
configured to place all logged-in users into configured cgroups? Is there
anything else you can think of that could be abused?
(I realize overlayfs isn't upstream yet so the question may not be all that
interesting to most people...)
thanks,
-serge
"Serge E. Hallyn" <[email protected]> writes:
> Hi Eric,
>
> most filesystems cannot be mounted in a non-init user namespace because we
> don't trust the superblock parsers to DTRT when handed garbage.
Correct, and mostly this is plain conservatism and not a real
limitation. As most distro's and thus most users of linux do trust
filesystem superblock parsers to not behave incorrectly when handed
garbage. At least for the common linux filesystems. And filesystems
like ext4 already handle bug reports from this case.
The larger practical issue is acl handling, and uid/gid translation when
not mounted in the initial user namespace.
> I was
> wondering if you had any ideas on ways that allowing root in a non-init userns
> to mount an overlayfs fs would be dangerous? There's no superblock parsing in
> that case at all; writes end up being allowed if and only if the userid owning
> the 'upper' (writeable) layer is mapped into the userns. Near as I can tell
> it should be quite safe. But my imagination isn't the most active.
Other than overlayfs not being mature enough to merge into the kernel at
this point. I would expect anyone hostile would read one of Al Viro's
scathing reviews and go ah-ha that is how I can exploit overlay fs.
> I assume there would be concerns about memory usage if the system is not
> configured to place all logged-in users into configured cgroups?
Yes. And I am not yet certain if the memory cgroup is stable in cgroup
OOM conditions especially when limiting kernel memory.
> Is there
> anything else you can think of that could be abused?
Not off the top of my head. My preference would be to look at fuse
first, and sort that out. It would be silly be doable to implement
overlay in userspace if we had a fuse filesystem we could trust.
And fuse is mostly trustable. There are just silly technical details
that haven't been worked through, and I am conservative enough to not
rush those details.
> (I realize overlayfs isn't upstream yet so the question may not be all that
> interesting to most people...)
There is a lot of work to get the vfs where it closer to the point where
it can reasonably support overlayfs.
Eric
p.s. You might have a little more luck with this question if you
included [email protected], or possibly the container lists.