This includes 1 security fix:
- net/http: CrossOriginProtection bypass patterns are over-broad
When passing patterns to CrossOriginProtection.AddInsecureBypassPattern,
requests that would have redirected to those patterns (e.g. without a trailing
slash) were also exempted, which might be unexpected.
Thanks to Marco Gazerro for reporting this issue.
This is CVE-2025-47910 and Go issue https://go.dev/issue/75054.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.24.7
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This change moves the `system.SecurityOpt` type and `system.DecodeSecurityOptions` function to the client and adds a set of unit tests to capture current implementation. This change also create a set of daemon backend copies for usage.
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
The moby codebase is now able to handle containerd errdefs errors directly
so there's no need to wrap a c8d "NotFound" error. We still need to look
if we can remove this function altogether; it's unclear what conditions
could result in the string-matching being needed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
newDriver, which creates a new instance of the bridge driver, is the
only place where the driver config field is set. So there's no need to
gate access to it with a mutex.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Libnetwork passes a map[string]any to the bridge driver's Register
function. This forces the daemon to convert its configuration into a
map, and the driver to convert that map back into a struct.
This is unnecessary complexity, and makes it harder to track down where
and how bridge driver configuration fields are set.
Refactor libnetwork to let the daemon register the bridge.Configuration
directly through a new option `OptionBridgeConfig`.
The bridge driver now takes a `Configuration` param that needs no
special treatment.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
makeDriverConfig is written in such a way that it seems to support
label-based driver configuration. That is, you could hypothetically use
labels starting with `com.docker.network.driver.<driver-name>.` to
define the configuration of a driver.
These labels come from the Controller's `cfg.Labels` which are set by
the daemon through libnet's OptionLabels which takes the list of labels
set on the daemon through dockerd's --label flag, or the equivalent
daemon.json field.
However, the daemon forbids setting labels that start with
`com.docker.*`. For instance:
label com.docker.network.driver.bridge.EnableProxy=false is not allowed: the namespaces com.docker.*, io.docker.*, and org.dockerproject.* are reserved for internal use
Hence, this is dead code — remove it.
Also, makeDriverConfig is checking if the Controller's cfg field is
nil... But the Controller struct is instantiated in a single place (i.e.
NewController) and it always set that field. Drop that nil check too.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Commit 0ca7ac325 was merged before a review comment was addressed.
Update the warning message returned by handlePortBindingsBC to handle
the case where multiple empty port bindings slices are sent to the API.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Not exactly sure what errors we can expect here if the process failed
to start, but logging as a warning instead of discarding won't do harm.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This argument is set from ExecConfig.ID, which we refer to as "execID"
in most places; rename the argument to match that terminology.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use a named output variable to more clearly indicate what error is being
checked, and scope `err` variables used in this function.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This reverts commit dbb47f63ab, which
added these rules to hide loopback devices from udisks. These rules
were for devicemapper, which we no longer support, and use hard-coded
paths, making them not practical for other purposes.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
So far, on ContainerStart, the daemon was silently backfilling empty
PortBindings slices with a PortBinding with unspecified HostIP and
HostPort. This was done by github.com/docker/go-connections/nat.SortPortMap.
This backfilling doesn't make much sense, and we're trying to remove
that package. So, move the backfilling to the API server, keep it for
older API versions, deprecate it for API 1.52, and drop it for API 1.53
and above.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
This method is only used by the cnmallocator to allocate Swarm-scoped
network resources. Its only concrete implementation is in the ovmanager.
Other network drivers are implementing it too to adhere to the
driverapi.Driver interface, but they all return a 'not implemented'
error.
Extract this method into a separate interface, and add a dedicated
RegisterNetworkAllocator to the driver registry. Update the cnmallocator
to load 'network allocators' instead of 'drivers'.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
The cnmallocator package has a map of supported network drivers which
are registered using a pkg-local driver registry. This registry is then
used to load drivers, and if they have a 'local' DataScope, they aren't
used for anything. Drivers with a 'global' DataScope are called to
allocate cluster-wide network resources.
Instantiating builtin network drivers may have unintended side-effects
(e.g. the bridge driver registers a callback that should run when
firewalld is reloaded), so libnetwork has dummy '*manager' drivers that
do nothing but carry the same Capability than the original driver they
masquerade.
Put 'local drivers' (e.g. those with DataScope 'local') into a separate
list that just contains drivers' name, and don't register them into the
cnmallocator's driver registry.
Remove all the dummy '*manager' drivers as they're not needed anymore.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
This tests, when failing, only produced a non-informative "exit status 1",
which limits investigating why it failed.
This patch:
- Rewrites the parallel pushes to use an error-group, and asserts each
push to get the failure output of the command.
- Simplifies the Dockerfile that's used for building the test-image,
removing steps that were not needed for the test.
- Adds a cleanup step to make sure the images are deleted after the
test, or if the test fails (although the test-suite should already
handle this).
Before this, a failure looked like:
make BIND_DIR=. TEST_FILTER='TestConcurrentPush' test-integration-cli
=== FAIL: arm64.integration-cli TestDockerRegistrySuite/TestConcurrentPush (5.49s)
docker_cli_push_test.go:159: assertion failed: error is not nil: exit status 1: concurrent push failed with error: exit status 1
check_test.go:476: [dfa779e71fdf8] daemon is not started
--- FAIL: TestDockerRegistrySuite/TestConcurrentPush (5.49s)
With this patch applied:
make BIND_DIR=. TEST_FILTER='TestConcurrentPush' test-integration-cli
=== FAIL: arm64.integration-cli TestDockerRegistrySuite/TestConcurrentPush (2.47s)
docker_cli_push_test.go:156: assertion failed:
Command: /usr/local/cli-integration/docker push 127.0.0.1:5000/dockercli/busybox:push2nosuch
ExitCode: 1
Error: exit status 1
Stdout: The push refers to repository 127.0.0.1:5000/dockercli/busybox
Stderr: tag does not exist: 127.0.0.1:5000/dockercli/busybox:push2nosuch
Failures:
ExitCode was 1 expected 0
Expected no error
docker_cli_push_test.go:160: assertion failed: error is not nil: exit status 1
check_test.go:476: [db77ef03a8fd8] daemon is not started
--- FAIL: TestDockerRegistrySuite/TestConcurrentPush (2.47s)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When building a non-native platform, it's not unpacked by default.
History tries to read the disk usage of all the layer and it doesn't
handle missing snapshots gracefully.
This patch fixes this.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
BuildKit emits some additional events during build and they are not
`build.Result` so don't fail if we encounter one.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Use `winio.RunWithPrivileges` to get the privileges.
It's better because it also locks the Go runtime thread so if the Go
scheduler decides to run this code on a different thread, it will still
have the expected privileges.
A naive attempt at fixing an error experienced by Docker Desktop user
when using Windows containers:
```
failed to register layer: re-exec error: exit status 1: output: hcsshim::ProcessUtilityVMImage \\?\C:\ProgramData\Docker\windowsfilter\<hash1>\UtilityVM: Access is denied.
failed to register layer: re-exec error: exit status 1: output: hcsshim::ProcessBaseLayer \\?\C:\ProgramData\Docker\windowsfilter\<hash2>: Access is denied.
failed to register layer: re-exec error: exit status 1: output: hcsshim::ProcessBaseLayer \\?\C:\ProgramData\Docker\windowsfilter\<hash3>: Access is denied.
```
Unfortunately I can't reproduce the issue on a Windows VM, but this
definitely won't hurt.
At least, I verified that the daemon still works on Windows.
Inspired by: https://github.com/containerd/containerd/issues/8206
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
