From: Chris Webb <chris@arachsys.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Building a BSD-jail clone out of namespaces
Date: Thu, 6 Jun 2013 22:51:52 +0100 [thread overview]
Message-ID: <20130606215150.GG17158@arachsys.com> (raw)
In-Reply-To: <871u8f89g5.fsf@xmission.com> <87ehcf8aef.fsf@xmission.com>
"Eric W. Biederman" <ebiederm@xmission.com> writes:
> Hmm. I guess it depends on how your VM is reading them. If it is
> blocked based access to the filesystem you have a problem. If the VM
> is effectively NFS mounting the filesystem you can do all kinds of
> things.
>
> It is possible to just change the user namespace and setup your mapping,
> effectively running your VM in the user namespace, and that would allow
> the VM to see your mapped uids.
In some cases I was thinking of mounting a filesystem directly from a block
device, but more often it would be directories in a local host filesystem.
I use qemu's built in virtio 9p-over-pci to pass these in at present.
So in principle, that does mean I could store UIDs translated and wrap
everything else I do at host level in a userns translation layer as well,
but it's quite an intrusive thing to do and I imagine it would preclude
lightweight throwaway containers where I share the host filesystem read-only
into a container.
This is why I was quite keen to avoid mangled ownerships in the host
filesystems at all, but from what you say, that goal sounds like this might
be rather tricky to achieve.
> There are too many things in /proc and /sys and similar that
> grant access to uid == 0.
Ah yes, I can see why this is a thorny one. Is it just the synthetic
filesystems like /proc and /sys that are the problem, or are there loads of
other places in the kernel that assume uid == 0 implies privilege? I.e. is
it 'just' a matter of somehow securing access to procfs and sysfs, or a much
wider issue?
Best wishes,
Chris.
next prev parent reply other threads:[~2013-06-06 21:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 16:10 Building a BSD-jail clone out of namespaces Chris Webb
2013-06-06 16:35 ` Eric W. Biederman
2013-06-06 16:46 ` Chris Webb
2013-06-06 16:56 ` Eric W. Biederman
2013-06-06 21:51 ` Chris Webb [this message]
2013-06-07 4:06 ` Eric W. Biederman
2013-06-07 12:58 ` Chris Webb
2013-06-27 13:43 ` Chris Webb
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=20130606215150.GG17158@arachsys.com \
--to=chris@arachsys.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.