There's no need to warn that "ip-forwarding" is disabled
if a container doesn't use networking.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 27f34593eac04fa5e43a540eb13b20d739169140
Component: engine
The filtering is made server-side, and the following filters are
supported:
* is-official (boolean)
* is-automated (boolean)
* has-stars (integer)
Signed-off-by: Fabrizio Soppelsa <fsoppelsa@mirantis.com>
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: e009ebdf4c0bf0ff64da8d48eefad63d0644de3e
Component: engine
Containers using the host network stack (--net=host)
are not affected by "ip-forwarding" being disabled,
so there's not need to show a warning.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 5fb7f9b29e9a85f36d02c4ecec6c04498fdb4315
Component: engine
This improves reliability by doing parsing of potentially untrusted data
in a separate process. It opens the door for further security improvements
if we can lock down the reexec-ed process. It also improves import
performance by only taking the backup and restore privileges once, for the
whole process.
Signed-off-by: John Starks <jostarks@microsoft.com>
Upstream-commit: b3bc5e0fe4c62b1c0193fc19777b22636368b551
Component: engine
Removing the call to Shutdown from within Signal in order to rely on waitExit handling the exit of the process.
Signed-off-by: Stefan J. Wernli <swernli@microsoft.com>
Upstream-commit: a5b64f2847501bc377c77a989df060646f2d87f8
Component: engine
This fix tries to address issues raised in #20936 and #22443
where `docker pull` or `docker push` fails because of the
concurrent connection failing.
Currently, the number of maximum concurrent connections is
controlled by `maxDownloadConcurrency` and `maxUploadConcurrency`
which are hardcoded to 3 and 5 respectively. Therefore, in
situations where network connections don't support multiple
downloads/uploads, failures may encounter for `docker push`
or `docker pull`.
This fix tries changes `maxDownloadConcurrency` and
`maxUploadConcurrency` to adjustable by passing
`--max-concurrent-uploads` and `--max-concurrent-downloads` to
`docker daemon` command.
The documentation related to docker daemon has been updated.
Additional test case have been added to cover the changes in this fix.
This fix fixes#20936. This fix fixes#22443.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 7368e41c07c21a1e2c6a49abecd1c2fc76404e49
Component: engine
This gives discovery a chance to initialize, particularly if the K/V
store being used is in a container.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 2dce79e05ab8f8fd22ca7b2f73121b2d7723f7cf
Component: engine
Currently the default seccomp profile is fixed. This changes it
so that it varies depending on the Linux capabilities selected with
the --cap-add and --cap-drop options. Without this, if a user adds
privileges, eg to allow ptrace with --cap-add sys_ptrace then still
cannot actually use ptrace as it is still blocked by seccomp, so
they will probably disable seccomp or use --privileged. With this
change the syscalls that are needed for the capability are also
allowed by the seccomp profile based on the selected capabilities.
While this patch makes it easier to do things with for example
cap_sys_admin enabled, as it will now allow creating new namespaces
and use of mount, it still allows less than --cap-add cap_sys_admin
--security-opt seccomp:unconfined would have previously. It is not
recommended that users run containers with cap_sys_admin as this does
give full access to the host machine.
It also cleans up some architecture specific system calls to be
only selected when needed.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: a01c4dc8f85827f32d88522e5153dddc02f11806
Component: engine
use a consistent approach for checking if the
backing filesystem is compatible with the
storage driver.
also add an error-message for the AUFS driver if
an incompatible combination is found.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 1fc0acc9ae77752858057d1f6f8487ccd82372be
Component: engine
Since 1.9, driver specific log tag options
`syslog-tag`
`gelf-tag`
`fluentd-tag`
have been deprecated in favor of the generic tag
option which is standard across different logging
drivers.
This fix removed the deprecated driver specific
log tag options of `syslog-tag`, `gelf-tag`,
`fluentd-tag` for 1.12 and updated the docs.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: a20b02b9158c283402d174926c84e657e53b17a1
Component: engine
The jsonlog logger currently allows specifying envs and labels that
should be propagated to the log message, however there has been no way
to read that back.
This adds a new API option to enable inserting these attrs back to the
log reader.
With timestamps, this looks like so:
```
92016-04-08T15:28:09.835913720Z foo=bar,hello=world hello
```
The extra attrs are comma separated before the log message but after
timestamps.
Without timestaps it looks like so:
```
foo=bar,hello=world hello
```
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: bd9d14a07b9f1c82625dc8483245caf3fa7fe9e6
Component: engine
This fix tries to addess the issue in #21956 where `docker inspect`
will overwrite the log config options with default option even when
the `--log-driver` is not empty and `--log-opt` is empty. In this
situation, `docker inspect` and `docker run` is different.
With the introduction of #21153, the `HostConfig` will always have
the correct log-driver and log-opt values.
However, the previous processing of `docker inspect` was not updated
after the change in #21153. This results in the incorrect behavior.
This fix addresses this issue by updating `docker inspect` to conform
to #21153 so the the behavior of `docker inspect` and `docker run` is
consistent.
A integration test has been added to cover this fix.
This fix fixes#21956. This fix is related to #21153.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 4b5404f15ed2944ca2d994f52618338c52611352
Component: engine
This flag can be set on disk if the daemon were to crash or error out
while trying to remove container in which case subsequent tries to
delete the container would all fail.
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Upstream-commit: ce724731973159a4fcedf16d0996571684cc3843
Component: engine
This add a new filter to 'docker network ls'
to allow filtering by driver-name.
Contrary to "ID" and "name" filters, this
filter only supports an *exact* match.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 23e418b6c966a43a463a064053ce0c741b8e5159
Component: engine