Mount propagation flags don't work #263
Comments
|
Closing as #264 was merged. |
stefanberger
pushed a commit
to stefanberger/runc
that referenced
this issue
Sep 8, 2017
*: printable documents
stefanberger
pushed a commit
to stefanberger/runc
that referenced
this issue
Sep 8, 2017
At the end of the list, to match its position in the README. This catches opencontainers#107 up with opencontainers#263, which I'd missed during one of the opencontainers#107 rebases. Signed-off-by: W. Trevor King <wking@tremily.us>
stefanberger
pushed a commit
to stefanberger/runc
that referenced
this issue
Sep 8, 2017
Defaulting to whichever PANDOC is first in your path. This mirrors the existing DOCKER handling. Folks who want to use the old path can run: $ make PANDOC=vbatts/pandoc ... I'm not sure why 4ee036f (*: printable documents, 2015-12-09, opencontainers#263) went with a variable for 'docker' but a hard-coded path for 'pandoc'. I expect it was just oversight. Signed-off-by: W. Trevor King <wking@tremily.us>
stefanberger
pushed a commit
to stefanberger/runc
that referenced
this issue
Sep 8, 2017
# 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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently if I specify a mount propagation flag in "options", it does not take effect. For example try following bind mount in config.json.
{
"type": "bind",
"source": "/root/mnt-source",
"destination": "/root/mnt-dest",
"options": "rbind,shared"
}
And inside container check the properties of mount.
$ findmnt -o TARGET,PROPAGATION /root/mnt-dest
/root/mnt-dest private
It continues to be private, despite the fact user requested for it to be "shared".
The text was updated successfully, but these errors were encountered: