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

*: Avoid creation panics when 'process' and 'linux' are unset #1726

Closed
wants to merge 4 commits into from

Conversation

wking
Copy link
Contributor

@wking wking commented Feb 20, 2018

process has been optional since opencontainers/runtime-spec#701, and linux has been optional since at least opencontainers/runtime-spec#414. This pull-request makes a few pivots so runc can handle something like the spec's minimal config. I actually tested with:

{
  "ociVersion": "1.0.0",
  "root": {
    "path": "/"
  }
}

because the runtime crashes without access to a container-side /proc (I have syndtr/gocapability#14 open to address part of this, but other parts would take more work). With the changes in this PR, runc create test succeeded with that configuration. It also mucked up my local terminal creation (although I rebooted without digging into exactly why), so take care when testing this yourself.

There's some previous discussion on moving the LookPath call starting here.

As it can be since opencontainers/runtime-spec@c41ea83d (config: Make
process optional, 2017-02-27, opencontainers/runtime-spec#701).

Signed-off-by: W. Trevor King <wking@tremily.us>
As it can be since opencontainers/runtime-spec@c41ea83d (config: Make
process optional, 2017-02-27, opencontainers/runtime-spec#701).

Signed-off-by: W. Trevor King <wking@tremily.us>
As it can be since at least opencontainers/runtime-spec@b373a155
(config: Split platform-specific configuration into its own section,
2016-05-02, opencontainers/runtime-spec#414).

Signed-off-by: W. Trevor King <wking@tremily.us>
This avoids a panic for containers that do not set Process.  And even
if Process was set, there is no reason to require the executable to be
available *at create time* [1].  Subsequent activity could be
scheduled to get a binary in place at the configured location before
'start' is called.

[1]: opencontainers#827 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>
@hqhq
Copy link
Contributor

hqhq commented Feb 22, 2018

LGTM

Approved with PullApprove

@@ -186,6 +181,13 @@ func (l *linuxStandardInit) Init() error {
return newSystemErrorWithCause(err, "init seccomp")
}
}
if len(l.config.Args) == 0 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We want to validate this on creation not after we have done all this work. Change the above code to if process == nil error out

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words, there is no reason to do 90% of container creation if we get to the end and we cannot run the container because process == nil

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words, there is no reason to do 90% of container creation if we get to the end and we cannot run the container because process == nil

The point of this PR is allowing create for containers with no process (catching up with opencontainers/runtime-spec#701). You can't start those containers, which is why we have this check here, but we certainly don't want to error those out during create.

return fmt.Errorf("cannot use console socket if runc will not detach or allocate tty")
}
return nil
}

func validateProcessSpec(spec *specs.Process) error {
if spec == nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be an error case

@cyphar
Copy link
Member

cyphar commented Feb 23, 2018

@wking Regarding the /proc issue -- this is something I've been thinking about for a while. To cut a very long story short, there doesn't appear to be a way (given the current set of kernel facilities at our disposal) to safely create a container without mounting at least /proc in the container's PID namespace -- so it breaking really shouldn't be a surprise IMO. However there are also other issues that crop up with regards to /proc when you think about malicious container processes -- and at the moment there is literally no kernel facility that can protect against some kinds of attacks (AFAICS, and I've discussed this with some LXC folks and they agree...).

@AkihiroSuda
Copy link
Member

needs rebase

@kolyshkin
Copy link
Contributor

The second and the third commits are obsoleted by

The first one and the last one doesn't make much sense to me. Yet, if needed, please open a new PR.

@kolyshkin kolyshkin closed this Jun 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants