From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
stgraber@ubuntu.com, apw@canonical.com
Subject: Re: overlayfs mounts in user namespaces
Date: Mon, 10 Feb 2014 13:39:44 -0800 [thread overview]
Message-ID: <8738jqbqan.fsf@xmission.com> (raw)
In-Reply-To: <20140210195133.GA10107@mail.hallyn.com> (Serge E. Hallyn's message of "Mon, 10 Feb 2014 20:51:33 +0100")
"Serge E. Hallyn" <serge@hallyn.com> 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 linux-fsdevel@vger.kernel.org, or possibly the container lists.
prev parent reply other threads:[~2014-02-10 21:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-10 19:51 overlayfs mounts in user namespaces Serge E. Hallyn
2014-02-10 21:39 ` Eric W. Biederman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8738jqbqan.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=apw@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=stgraber@ubuntu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox