Runsc will not split any value for a given `env`, the
behavior is consistent with runc. Each env variable
will be passed by respective `env`.
Fix#11885
PiperOrigin-RevId: 780337902
Previously we were only looking at stdin, which could be a pty but other stdio
fds might be redirected. In that case, we can incorrectly end up using the
stdin fd as *the* console fd, and sending all stdout/stderr to that FD,
ignoring the redirect.
Note that the behavior was actually flaky because the mechanism for choosing
which stdio fd to treat as *the* pty fd is non-deterministic (due to the map
iteration in fdimport/fdimport.go:Import) and so sometimes we would choose
the correct one.
This CL also cleans up `argsFromProcess` and `argsFromCLI`, which were setting
their `FilePayload` unnecessarily, since it is always set in `Execute`.
Fixes#11350Fixes#11349
PiperOrigin-RevId: 716733446
This is consistent with runc. This fixes several bugs with runsc exec:
- When --process flag is specified, the process spec should be validated. The
process spec should not inherit values from the OCI spec except capabilities.
Earlier, we were setting WorkingDirectory and Envv from the spec if these
were not set in the process file.
- When --process flag is not specified, we should use the Process defined in
the container spec as the base and append the following flags onto that
process spec. Earlier if these flags were specified, we were not using the
container spec values and just setting to these passed flags, hence making it
look like runsc is "clearing" these fields when their flags are passed.
- additional-gids
- cap
- env
- When --process flag is not specified, we should use the following values
defined in the container spec's Process. Those values should be selectively
overridden when the corresponding flag is set. Earlier, we were always using
the flag values, even when the flag was not set. One implication was that we
were always running with UID=GID=0 when --process and --user are not set.
- user
- cwd
- When --cap is set, it should not append to the Inheritable capabilities
defined in the spec. And it should only be appended to Ambient if Inheritable
in the original spec is non-empty.
Fixes#11108
PiperOrigin-RevId: 694642077
This commit adds support for program execution via a host file
descriptor. To make use of this feature, the host file descriptor must
be provided to the --exec-fd argument. For example,
exec 3</usr/bin/echo
runsc exec --exec-fd=3 mycontainer hello world
will run the host's echo binary inside gVisor. In this case, "hello" is
supplied to echo as argv[0]. As a result, the output of the above
command is "world".
This feature is useful for bootstrapping unknown guest environments and
allows static executables to perform setup actions inside the container
while they need not be part of the guest file system.
This commit implements file descriptor passing from the host to the
guest. It implements a --pass-fd flag that can be specified multiple
times with FD numbers from the host that will be inserted into the file
descriptor table of the guest.
'docker exec' was getting CAP_NET_RAW even when --net-raw=false
because it was not filtered out from when copying container's
capabilities.
PiperOrigin-RevId: 272260451
Based on the guidelines at
https://opensource.google.com/docs/releasing/authors/.
1. $ rg -l "Google LLC" | xargs sed -i 's/Google LLC.*/The gVisor Authors./'
2. Manual fixup of "Google Inc" references.
3. Add AUTHORS file. Authors may request to be added to this file.
4. Point netstack AUTHORS to gVisor AUTHORS. Drop CONTRIBUTORS.
Fixes#209
PiperOrigin-RevId: 245823212
Change-Id: I64530b24ad021a7d683137459cafc510f5ee1de9
