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

Allow numeric groups for containers without /etc/group #313

Merged
merged 1 commit into from Oct 5, 2015
Merged

Allow numeric groups for containers without /etc/group #313

merged 1 commit into from Oct 5, 2015

Conversation

ghost
Copy link

@ghost ghost commented Oct 4, 2015

/etc/groups is not needed when specifying numeric group ids. This
change allows containers without /etc/groups to specify numeric
supplemental groups.

Signed-off-by: Sami Wagiaalla swagiaal@redhat.com

/etc/groups is not needed when specifying numeric group ids. This
change allows containers without /etc/groups to specify numeric
supplemental groups.

Signed-off-by: Sami Wagiaalla <swagiaal@redhat.com>
@pmorie
Copy link
Contributor

pmorie commented Oct 5, 2015

@rhatdan @mrunalp

@mrunalp
Copy link
Contributor

mrunalp commented Oct 5, 2015

@cyphar ping

@wking
Copy link
Contributor

wking commented Oct 5, 2015

On Sun, Oct 04, 2015 at 04:55:47PM -0700, Sami Wagiaalla wrote:

/etc/groups is not needed when specifying numeric group ids.

I'm not sure what runC's current spec is for user/group IDs, but I
think semantics I proposed 1 for the in-flight
opencontainers/runtime-spec#191 would make all this explicit. So folks
specifying additionalGroupNames would require a successful lookup in
/etc/groups, but bundle-authors would be free to use additionalGids
for numeric IDs that didn't need a lookup.

@cyphar
Copy link
Member

cyphar commented Oct 5, 2015

LGTM

/cc @tianon @crosbymichael

@tianon
Copy link
Member

tianon commented Oct 5, 2015

Ah, pretty simple change; LGTM too

@mrunalp
Copy link
Contributor

mrunalp commented Oct 5, 2015

Thanks! LGTM

mrunalp pushed a commit that referenced this pull request Oct 5, 2015
Allow numeric groups for containers without /etc/group
@mrunalp mrunalp merged commit 0b9e7af into opencontainers:master Oct 5, 2015
@ghost
Copy link
Author

ghost commented Oct 5, 2015

Thanks for the quick turnaround everyone!

stefanberger pushed a commit to stefanberger/runc that referenced this pull request Sep 8, 2017
json-schema: initial pass at schema and validator
stefanberger pushed a commit to stefanberger/runc that referenced this pull request Sep 8, 2017
Also:

* Update the link to Go bindings after 7bf06d5 (source and schema:
  differentiate with examples, 2015-12-18, opencontainers#276).
* Add a reference to the JSON Schema after cdcabde (schema: JSON
  Schema and validator for `config.json`, 2016-01-19, opencontainers#313).

It's pretty clear that the Go bindings cannot be canonical on their
own, because they do not define limits (e.g. the 0 through 512 range
for FileMode).  The JSON Schema is closer, but still does not cover
everything (e.g. "a directory must exist at root.path").  Both the Go
bindings and the JSON Schema could grow to cover the full spec by
adding that sort of thing to comments and descriptions, but that's not
how things seem to be working now.

Signed-off-by: W. Trevor King <wking@tremily.us>
stefanberger pushed a commit to stefanberger/runc that referenced this pull request 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>
stefanberger pushed a commit to stefanberger/runc that referenced this pull request Sep 8, 2017
The JSON Schema requirement dates back to cdcabde (schema: JSON
Schema and validator for `config.json`, 2016-01-19, opencontainers#313), but the
property has been explicitly optional in the Markdown spec since
7ac41c6 (config.md: reformat into a standard style, 2015-06-30).

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants