-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot mount devpts or sysfs with a user namespace (as of v0.0.3) #225
Comments
On Tue, Aug 25, 2015 at 08:10:59PM -0700, Mrunal Patel wrote:
Hmm, which channel/day? The most recent estesp comments in
I'm running 4.1.0, if that helps. |
This is the kernel patch which seems to be the culprit for the issue: http://www.spinics.net/lists/linux-fsdevel/msg86256.html It went into one of the Linux 4.2-rc's, but Ubuntu recently brought it into their 3.16.0-45 kernel update, which is how I happened to catch it. @wking where are you sourcing your 4.1 kernel from? If from a distro maybe they backported this patch into your kernel? Here is a direct link to the upstream commit: torvalds/linux@1b852bc#diff-3fbed1fd4d15699b74b30cabf5be8133 which shows the 4.2 tag/lineage. |
On Tue, Aug 25, 2015 at 08:42:58PM -0700, Phil Estes wrote:
I built it locally from 1, tag v4.1, so I don't have If we suspect a kernel issue, I can try bisecting to actually find the |
I tested with the kernel 4.2 on Fedora rawhide. There are two issues:
With the above two changes to the config.json, I was able to bring up a container in the busybox rootfs. |
On Mon, Aug 31, 2015 at 03:39:47PM -0700, Mrunal Patel wrote:
This works for me on my vanilla 4.1. |
Works for me with those changes as well in runC. The original report I got was someone testing my Docker-based user namespace patchset before and after the Ubuntu kernel update I mentioned, so it might be trickier to get a test scenario there, although I could provide a modified |
This has been resolved. |
Expand on the definition of our ops
This slipped through the renumbering in 7117ede (Expand on the definition of our ops, 2015-10-13, opencontainers#225). Signed-off-by: W. Trevor King <wking@tremily.us>
# digest/hashing target Most of this has spun off with [1], and I haven't heard of anyone talking about verifying the on-disk filesystem in a while. My personal take is on-disk verification doesn't add much over serialized verification unless you have a local attacker (or unreliable disk), and you'll need some careful threat modeling if you want to do anything productive about the local attacker case. For some more on-disk verification discussion, see the thread starting with [2]. # distributable-format target This spun off with [1]. # lifecycle target I think this is resolved since 7713efc (Add lifecycle for containers, 2015-10-22, opencontainers#231), which was committed on the same day as the ROADMAP entry (4859f6d, Add initial roadmap, 2015-10-22, opencontainers#230). # container-action target Addressed by 7117ede (Expand on the definition of our ops, 2015-10-13, opencontainers#225), although there has been additional discussion in a7a366b (Remove exec from required runtime functionalities, 2016-04-19, opencontainers#388) and 0430aaf1 (Split create and start, 2016-04-01, opencontainers#384). # validation and testing targets Validation is partly covered by cdcabde (schema: JSON Schema and validator for `config.json`, 2016-01-19, opencontainers#313) and subequent JSON Schema work. The remainder of these targets are handled by ocitools [3]. # printable/compiled-spec target The bulk of this was addressed by 4ee036f (*: printable documents, 2015-12-09, opencontainers#263). Any remaining polishing of that workflow seems like a GitHub-issue thing and not a ROADMAP thing. And publishing these to opencontainers.org certainly seems like it's outside the scope of this repository (although I think that such publishing is a good idea). [1]: https://github.com/opencontainers/image-spec [2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/xo4SQ92aWJ8/NHpSQ19KCAAJ Subject: OCI Bundle Digests Summary Date: Wed, 14 Oct 2015 17:09:15 +0000 Message-ID: <CAD2oYtN-9yLLhG_STO3F1h58Bn5QovK+u3wOBa=t+7TQi-hP1Q@mail.gmail.com> [3]: https://github.com/opencontainers/ocitools Signed-off-by: W. Trevor King <wking@tremily.us>
This wording is descended from 7117ede (Expand on the definition of our ops, 2015-10-13, opencontainers#225), but the idea is covered generically by e53a72b (Clarify the operation is not for command-line api, 2016-05-24, opencontainers#450), so we no longer need a create-specific note. Especially in the lifecycle docs, where there's already enough going on without this low-level detail. Signed-off-by: W. Trevor King <wking@tremily.us>
This wording landed without comment as part of 7117ede (Expand on the definition of our ops, 2015-10-13, opencontainers#225). However, I'm not entirely clear on the exception it's making. It may be trying to say something like: Just because you were authorized to manage that container when you created it doesn't mean you're still authorized to perform operation X on it now. Maybe you've lost privileges in the meantime. But as far as compliance testing is concerned, the same test harness will be calling 'create' and the subsequent operations. That harness will be reporting MUST violations if the runtime refuses a subsequent operation, and removing the access-control loophole makes it more obvious that the runtime's refusal is non-compliant. Signed-off-by: W. Trevor King <wking@tremily.us>
@crosbymichael Can you please point me to the commit that fixed this issue? I am hitting this with runc rc2 version. Or was it fixed in upstream kernel? Thanks! |
While adding user namespaces to my bundle, I had to drop the
devpts
andsysfs
mounts from runC's default config, and I also had to dropro
from runC's default cgroup-mount options. Restoring them to myconfig.json.template
leads to:with the
devpts
entry,with the
sysfs
entry, and:with
ro
in thecgroups
entry. I haven't been able to figure out why I'm getting these mount errors. If I drop my user namespacing, the errors go away. Is this a runC bug? A user-namespace limitation? A bug in my config template? I'm happy to help with further digging, but I could use a few hints pointing me in a useful direction. Perhaps this is what @LK4D4 was thinking about when he mentioned reconsidering default mounts for unprivileged functionality.The text was updated successfully, but these errors were encountered: