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.

Sign up for GitHub

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

Add extra file descriptors to Process #100

Closed
wants to merge 1 commit into from
Closed

Add extra file descriptors to Process #100

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions config.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -95,6 +95,7 @@ See links for details about [mountvol](http://ss64.com/nt/mountvol.html) and [Se
* **cwd** (string, optional) is the working directory that will be set for the executable.
* **env** (array of strings, optional) contains a list of variables that will be set in the process's environment prior to execution. Elements in the array are specified as Strings in the form "KEY=value". The left hand side must consist solely of letters, digits, and underscores `_` as outlined in [IEEE Std 1003.1-2001](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html).
* **args** (string, required) executable to launch and any flags as an array. The executable is the first element and must be available at the given path inside of the rootfs. If the executable path is not an absolute path then the search $PATH is interpreted to find the executable.
* **extraFiles** (array of int, optional) contains a list of open file descriptors that are passed to the process.

The user for the process is a platform-specific structure that allows specific control over which user the process runs as.
For Linux-based systems the user structure has the following fields:
Expand Down
6 changes: 6 additions & 0 deletions spec.go
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,9 @@
package specs

import (
"os"
)

// Spec is the base configuration for the container. It specifies platform
// independent configuration.
type Spec struct {
Expand Down Expand Up @@ -53,6 +57,8 @@ type Process struct {
// Cwd is the current working directory for the process and must be
// relative to the container's root.
Cwd string `json:"cwd"`
// ExtraFiles specifies open file descriptors that should be passed to the process.
ExtraFiles []os.File `json:"extraFiles"`
Copy link

Choose a reason for hiding this comment

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

@mrunalp
This might be ExtraFiles []*os.Filejson:"extraFiles"``

Copy link
Member

Choose a reason for hiding this comment

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

since this is supposed to be a config that is serialized I highly doubt this will work at all

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@crosbymichael @philips This feature makes more sense as a dynamic property. We could have an environment variable passed to the runtime that could be a list of open fds that it should leak into the container process. For e.g.

sh# OCI_PASS_FDS="3,4" runc 4</path/to/some/file # 3 is passed by systemd

WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

what is your use case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@crosbymichael Systemd socket activated containers http://0pointer.de/blog/projects/socket-activated-containers.html
We could either make this generic or leave it out and have the runtimes support systemd environment variables for activation.

Copy link
Member

Choose a reason for hiding this comment

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

i think having runtime support for LISTEN_FDS and doing passthrough would be better than adding this runtime information in the spec that is to be serialized.

Copy link
Contributor

Choose a reason for hiding this comment

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

On Fri, Aug 21, 2015 at 11:16:46AM -0700, Michael Crosby wrote:

  • // ExtraFiles specifies open file descriptors that should be passed to the process.
  • ExtraFiles []os.File json:"extraFiles"

i think having runtime support for LISTEN_FDS and doing
passthrough would be better than adding this runtime information in
the spec that is to be serialized.

You're still serializing those file descriptors into the environment
variable, no? With #88 and the LISTEN_FDS suggestion, that would mean
the runtime would have to check:

  • The static config.json
  • The more dynamic runtime.json
  • The LISTEN_FDS environment variable

to figure out how to create the container and launch the application.
Personally, I see no problem with mutating a single config to launch
the container (so the runtime only has to look in one place) [1,2].
But if we do end up getting a second place to put any configuration
considered “too host-specific for config.json”, then I don't see a
need to go further than a runtime.json.

Copy link
Member

Choose a reason for hiding this comment

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

@wking no

Copy link
Contributor

Choose a reason for hiding this comment

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

On Fri, Aug 21, 2015 at 11:25:04AM -0700, Michael Crosby wrote:

  • // ExtraFiles specifies open file descriptors that should be passed to the process.
  • ExtraFiles []os.File json:"extraFiles"

@wking no

Then why not use environment variables for all runtime-specific
settings? If there is a need to use all of:

how do we make decisions about sorting between them? E.g. why use
LISTEN_FDS for passing file descriptors through and runtime.json to
pass namespace paths through?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@crosbymichael SGTM

}

// Root contains information about the container's root filesystem on the host.
Expand Down