State the default user a container process runs #417

amitsaha · 2016-05-01T09:17:11Z

This patch adds information about the default user/group a process runs on Linux.

Signed-off-by: Amit Saha amitsaha.in@gmail.com

vbatts · 2016-05-01T13:18:40Z

SGTM, but the commit is not signed (try git commit -s --amend .)
Also, as a nit on the commit message, the subject line more appropriately be "config.md: args is an array of strings"

Signed-off-by: Amit Saha <amitsaha.in@gmail.com>

amitsaha · 2016-05-01T13:26:45Z

Thanks @vbatts , done.

wking · 2016-05-01T22:06:48Z

On Sun, May 01, 2016 at 02:17:13AM -0700, Amit Saha wrote:

This patch adds information about the default user/group a process
runs on Linux.

I'm not sure this default is a good idea. For example, a config that
does not create a new user namespace may want the process to run as
the current user/group instead of as root. I think it's better to
follow unshare(1) and require folks who want a process to run as root
to specify that explicitly in their config.

$ unshare --user id
uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)
$ unshare --user --map-root-user id
uid=0(root) gid=0(root) groups=0(root),65534(nobody)

Wording for that approach would be something like (also pulling in
#412):

uid (int, required) specifies the user ID in the container
namespace. If unset, the runtime will not attempt to manipulate
the user ID (e.g. not calling setuid(2) or similar).

amitsaha · 2016-05-01T22:21:14Z

@wking But that is what is the default now, isn't it?

wking · 2016-05-01T22:37:58Z

On Sun, May 01, 2016 at 03:21:16PM -0700, Amit Saha wrote:

@wking But that is what is the default now, isn't it?

It's not in the spec, so the current default is “undefined” ;).
Bundle authors who expect this behavior may get it with runC (I'm not
sure), but may see different behavior on other runtimes (e.g. ccon-oci
will not call setuid 1). If we want to make the “default to root”
behavior explicit, I'd rather see that also land with motivation
explaining why it's a better approach than “do nothing by default”
2.

 Subject: Exposing platform defaults
 Date: Thu, 14 Jan 2016 15:36:26 -0800
 Message-ID: <20160114233625.GN6362@odin.tremily.us>

philips · 2016-05-04T17:17:32Z

I think the current text that makes it required is best. Implied behavior that goes straight to the highest privledge level isn't super helpful.

crosbymichael · 2016-05-04T17:17:43Z

Because we have uid/gid required in the spec we do not need to talk about what the default is. We made it required so we don't have to specify defaults for this.

amitsaha · 2016-05-06T00:53:51Z

PR #425

Since be59415 (Split create and start, 2016-04-01, opencontainers#384), it's possible for a container process to never execute user-specified code (e.g. you can call 'create', 'kill', 'delete' without calling 'start'). For folks who expect to do that, there's no reason to define process.args. The only other process property required for all platforms is 'cwd', but the runtime's idler code isn't specified in sufficient detail for the configuration author to have an opinion about what its working directory should be. On Linux and Solaris, uid and gid are also required. My preferred approach here is to make those optional and define defaults [1,2]: If unset, the runtime will not attempt to manipulate the user ID (e.g. not calling setuid(2) or similar). But the maintainer consensus is that they want those to be explicitly required properties [3,4,5]. With the current spec, one option could be to make process optional (with the idler's working directory unspecified) for OSes besides Linux and Solaris, but the main reason that Windows doesn't have a user property is that we don't know how to specify it [6]. I expect all platforms will have some sort of required user field, which means they'll all have to define 'process'. While I'm indenting the sub-properties, also wrap them to one line per sentence (style.md). [1]: opencontainers#417 (comment) [2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/DWdystx5X3A Subject: Exposing platform defaults Date: Thu, 14 Jan 2016 15:36:26 -0800 Message-ID: <20160114233625.GN6362@odin.tremily.us> [3]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-04-17.00.log.html#l-44 [4]: opencontainers#417 (comment) [5]: opencontainers#417 (comment) [6]: opencontainers#96 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>

Since be59415 (Split create and start, 2016-04-01, opencontainers#384), it's possible for a container process to never execute user-specified code (e.g. you can call 'create', 'kill', 'delete' without calling 'start'). For folks who expect to do that, there's no reason to define process.args. The only other process property required for all platforms is 'cwd', but the runtime's idler code isn't specified in sufficient detail for the configuration author to have an opinion about what its working directory should be. On Linux and Solaris, 'user' is also required for 'uid' and 'gid'. My preferred approach here is to make those optional and define defaults [1,2]: If unset, the runtime will not attempt to manipulate the user ID (e.g. not calling setuid(2) or similar). But the maintainer consensus is that they want those to be explicitly required properties [3,4,5]. With the current spec, one option could be to make process optional (with the idler's working directory unspecified) for OSes besides Linux and Solaris, but the main reason that Windows doesn't have a user property is that we don't know how to specify it [6]. I expect all platforms will have some sort of required user field, which means they'll all have to define 'process'. While I'm indenting the sub-properties, also wrap them to one line per sentence (style.md). [1]: opencontainers#417 (comment) [2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/DWdystx5X3A Subject: Exposing platform defaults Date: Thu, 14 Jan 2016 15:36:26 -0800 Message-ID: <20160114233625.GN6362@odin.tremily.us> [3]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-04-17.00.log.html#l-44 [4]: opencontainers#417 (comment) [5]: opencontainers#417 (comment) [6]: opencontainers#96 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>

Linux and Solaris both use the same POSIX-based structure (which I've moved to defs-linux.json). Windows likely needs a string-based structure, but we're punting on that until we have more feedback from the Windows folks [1]. Regardless of whether we have a Windows user structure yet, the maintainer consensus is that the property is required [2,3,4]. [1]: opencontainers#96 (comment) [2]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-04-17.00.log.html#l-44 [3]: opencontainers#417 (comment) [4]: opencontainers#417 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>

Since be59415 (Split create and start, 2016-04-01, opencontainers#384), it's possible for a container process to never execute user-specified code (e.g. you can call 'create', 'kill', 'delete' without calling 'start'). For folks who expect to do that, there's no reason to define process.args. The only other process property required for all platforms is 'cwd', but the runtime's idler code isn't specified in sufficient detail for the configuration author to have an opinion about what its working directory should be. On Linux and Solaris, 'user' is also required for 'uid' and 'gid'. My preferred approach here is to make those optional and define defaults [1,2]: If unset, the runtime will not attempt to manipulate the user ID (e.g. not calling setuid(2) or similar). But the maintainer consensus is that they want those to be explicitly required properties [3,4,5]. With the current spec, one option could be to make process optional (with the idler's working directory unspecified) for OSes besides Linux and Solaris, but the main reason that Windows doesn't have a user property is that we don't know how to specify it [6]. I expect all platforms will have some sort of required user field, which means they'll all have to define 'process'. While I'm indenting the sub-properties, also wrap them to one line per sentence (style.md). [1]: opencontainers#417 (comment) [2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/DWdystx5X3A Subject: Exposing platform defaults Date: Thu, 14 Jan 2016 15:36:26 -0800 Message-ID: <20160114233625.GN6362@odin.tremily.us> [3]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-04-17.00.log.html#l-44 [4]: opencontainers#417 (comment) [5]: opencontainers#417 (comment) [6]: opencontainers#96 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>

Since be59415 (Split create and start, 2016-04-01, opencontainers#384), it's possible for a container process to never execute user-specified code (e.g. you can call 'create', 'kill', 'delete' without calling 'start'). For folks who expect to do that, there's no reason to define process.args. The only other process property required for all platforms is 'cwd', but the runtime's idler code isn't specified in sufficient detail for the configuration author to have an opinion about what its working directory should be. On Linux and Solaris, 'user' is also required for 'uid' and 'gid'. My preferred approach here is to make those optional and define defaults [1,2]: If unset, the runtime will not attempt to manipulate the user ID (e.g. not calling setuid(2) or similar). But the maintainer consensus is that they want those to be explicitly required properties [3,4,5]. With the current spec, one option could be to make process optional (with the idler's working directory unspecified) for OSes besides Linux and Solaris. On Windows, username is optional, but it's not clear how intentional that was [6]. [1]: opencontainers#417 (comment) [2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/DWdystx5X3A Subject: Exposing platform defaults Date: Thu, 14 Jan 2016 15:36:26 -0800 Message-ID: <20160114233625.GN6362@odin.tremily.us> [3]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-04-17.00.log.html#l-44 [4]: opencontainers#417 (comment) [5]: opencontainers#417 (comment) [6]: opencontainers#618 Signed-off-by: W. Trevor King <wking@tremily.us>

Since be59415 (Split create and start, 2016-04-01, opencontainers#384), it's possible for a container process to never execute user-specified code (e.g. you can call 'create', 'kill', 'delete' without calling 'start'). For folks who expect to do that, there's no reason to define process.args. The only other process property required for all platforms is 'cwd', but the runtime's idler code isn't specified in sufficient detail for the configuration author to have an opinion about what its working directory should be. On Linux and Solaris, 'user' is also required for 'uid' and 'gid'. My preferred approach here is to make those optional and define defaults [1,2]: If unset, the runtime will not attempt to manipulate the user ID (e.g. not calling setuid(2) or similar). But the maintainer consensus is that they want those to be explicitly required properties [3,4,5]. With the current spec, one option could be to make process optional (with the idler's working directory unspecified) for OSes besides Linux and Solaris. On Windows, username is optional, but that was likely accidental [6]. So an unspecified 'process' would leave process.cwd and process.user unset. What that means for the implementation-defined container process between 'create' and 'start' is unclear, but clarifying how that is handled is a separate issue [7] independent of whether 'process' is optional or not. [1]: opencontainers#417 (comment) [2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/DWdystx5X3A Subject: Exposing platform defaults Date: Thu, 14 Jan 2016 15:36:26 -0800 Message-ID: <20160114233625.GN6362@odin.tremily.us> [3]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-04-17.00.log.html#l-44 [4]: opencontainers#417 (comment) [5]: opencontainers#417 (comment) [6]: opencontainers#618 (comment) [7]: opencontainers#700 Signed-off-by: W. Trevor King <wking@tremily.us>

On POSIX (currently Linux and Solaris), `uid` and `gid` are required. My preferred approach here is to make those optional and use platform defaults [1,2]: If unset, the runtime will not attempt to manipulate the user ID (e.g. not calling setuid(2) or similar). But the maintainer consensus is that they want those to be explicitly required properties [3,4,5]. The Windows `username`, on the other hand, was optional, although the default behavior is unclear. I see no discussion in f9e48e0 (Windows: User struct changes, 2016-09-14, opencontainers#565) or its pull-request discussion to suggest whether this was intentionally approved or not. When I asked whether the optional-ness was intentional, Michael said [6]: No, both should be made explicit unless there is something on windows that prohibits this. So this commit is making that happen. [1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/DWdystx5X3A [2]: opencontainers#417 (comment) Subject: Exposing platform defaults Date: Thu, 14 Jan 2016 15:36:26 -0800 Message-ID: <20160114233625.GN6362@odin.tremily.us> [3]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-04-17.00.log.html#l-44 [4]: opencontainers#417 (comment) [5]: opencontainers#417 (comment) [6]: opencontainers#618 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>

On POSIX (currently Linux and Solaris), `uid` and `gid` are required. My preferred approach here is to make those optional and use platform defaults [1,2]: If unset, the runtime will not attempt to manipulate the user ID (e.g. not calling setuid(2) or similar). But the maintainer consensus is that they want those to be explicitly required properties [3,4,5]. The Windows `username`, on the other hand, was optional, although the default behavior is unclear. I see no discussion in f9e48e0 (Windows: User struct changes, 2016-09-14, opencontainers#565) or its pull-request discussion to suggest whether this was intentionally approved or not. When I asked whether the optional-ness was intentional, Michael said [6]: No, both should be made explicit unless there is something on windows that prohibits this. However, when I filed a pull request to make the property required, John pushed back [7] and prefered implementation-defined default behavior. I'm still not clear if that satisfies Michael's "prohibits" condition, but having optional user values is closer to my personal preference than requiring the property, and John seems to be fairly strongly against requiring the property, so this commit documents the default value to make the OPTIONAL-ness useful. I've also added the property to the JSON Schema for validation. The empty-string bit follows wording from 'annotations', and avoids ambiguity with the non-pointer Go property. I doubt empty-string usernames would work, and having the restriction in the spec allows for us to validate this in runtime-tools (vs. passing validation and then failing to launch a container when the runtime chokes on the empty string). [1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/DWdystx5X3A [2]: opencontainers#417 (comment) Subject: Exposing platform defaults Date: Thu, 14 Jan 2016 15:36:26 -0800 Message-ID: <20160114233625.GN6362@odin.tremily.us> [3]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-04-17.00.log.html#l-44 [4]: opencontainers#417 (comment) [5]: opencontainers#417 (comment) [6]: opencontainers#618 (comment) [7]: opencontainers#760 (comment) [8]: opencontainers#760 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>

config.md: State the default user a container process runs as

b685af5

Signed-off-by: Amit Saha <amitsaha.in@gmail.com>

crosbymichael closed this May 4, 2016

wking mentioned this pull request Jun 5, 2016

config: Make 'process.args' optional #489

Closed

wking mentioned this pull request Nov 10, 2016

Windows process.username optional but POSIX process.uid required? #618

Closed

wking mentioned this pull request Feb 2, 2017

config: Make 'process.args' optional #620

Closed

wking mentioned this pull request Apr 7, 2017

config: process.user.username is implementation-defined on Windows #760

Closed

wking mentioned this pull request Mar 12, 2018

config: Add VM-based container configuration section #949

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

State the default user a container process runs #417

State the default user a container process runs #417

amitsaha commented May 1, 2016

vbatts commented May 1, 2016

amitsaha commented May 1, 2016

wking commented May 1, 2016

amitsaha commented May 1, 2016

wking commented May 1, 2016

philips commented May 4, 2016

crosbymichael commented May 4, 2016

amitsaha commented May 6, 2016

State the default user a container process runs #417

State the default user a container process runs #417

Conversation

amitsaha commented May 1, 2016

vbatts commented May 1, 2016

amitsaha commented May 1, 2016

wking commented May 1, 2016

amitsaha commented May 1, 2016

wking commented May 1, 2016

philips commented May 4, 2016

crosbymichael commented May 4, 2016

amitsaha commented May 6, 2016