Skip to content
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

config-linux: Specify relationships for new namespaces #795

Closed

Commits on May 11, 2017

  1. config-linux: Specify relationships for new namespaces

    For more background on hierarchical namespaces, see [1].  For more
    background on the owning user namespace idea, see [2,3,4]).
    
    These were contentious [5,6], so they weren't part of the previous
    commit.  I still think we want to say something about these
    relationships.
    
    We already have some of "runtime namespace" conditions (e.g. when a
    type is not listed in linux.namespaces[]), so runtimes should already
    have implementation-specific wording around what the runtime
    namespaces are (we don't explicitly make them implementation-defined,
    although we probably should). Anyhow, that's not a new concept added
    by this commit.
    
    # Seeded namespaces
    
    For example, if you ask for a new uts namespace but do not set the
    optional hostname, having the seed defined means that the hostname in
    the container UTS namespace is well-defined (it will be whatever the
    hostname was in the runtime UTS namespace).
    
    This is less of an issue for the mount namespace, because with
    root.path REQUIRED, there's no way to avoid clobbering whatever mounts
    you got from your seed (which makes not asking for a new mount
    namespace exciting ;).
    
    # Hierarchical namespaces
    
    I think "I want this container to run in a new user/pid namespace that
    is a child of the runtime user/pid namespace" should be something that
    has a portable config expression. Otherwise it becomes very unclear
    what to put in the hostID field for (u|g)idMappings, because you don't
    know what namespace will be used to interpret the hostIDs.
    
    # Namespace ownership
    
    This is another case where I think specified clarity is essential. A
    new network namespace will not be very useful if you don't know who
    owns it.
    
    # Glossary changes
    
    In review, Mrunal and others pointed out that the new config-linux
    entries overlapped with the existing glossary entry [7].  I've
    addressed that in this commit by trimming the glossary entries down to
    fix them (namespaces are not all hierarchical and processes aren't
    always in leaves).  I've also dropped the handwavy and incorrect
    "children" sentence in favor of a link back to config-linux.md and the
    more specific RFC 2119 language from this commit.
    
    [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a7306ed8d94af729ecef8b6e37506a1c6fc14788
         nsfs: add ioctl to get a parent namespace, 2016-09-06
    [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6786741dbf99e44fb0c0ed85a37582b8a26f1c3b
         nsfs: add ioctl to get owning user namespace for ns file
         descriptor, 2016-09-06
    [3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5ff5ce6e20ee22511398bb31fb912466cf82a36
         nsfs: Add an ioctl() to return the namespace type, 2017-01-25
    [4]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d95fa3c76a66b6d76b1e109ea505c55e66360f3c
         nsfs: Add an ioctl() to return owner UID of a userns, 2017-01-25
    [5]: opencontainers#767 (comment)
    [6]: opencontainers#767 (comment)
    [7]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-05-10-21.03.log.html#l-115
         But I was talking so my log entries are sparse :/.
    
    Signed-off-by: W. Trevor King <wking@tremily.us>
    wking committed May 11, 2017
    Configuration menu
    Copy the full SHA
    cf8306e View commit details
    Browse the repository at this point in the history