A managed volume plugin could return a path containing dot-dot
elements that passed the propagated-mount string prefix check, then
escaped the host mount root when filepath.Join cleaned it. Sibling
paths sharing the same string prefix were also treated as propagated
paths.
Normalize returned paths in the plugin's rooted namespace. Use
filepath.Rel and filepath.IsLocal so only path-component descendants
are mapped through the propagated mount. Other paths remain confined
beneath the plugin rootfs.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Plugin specs built by (*v2.Plugin).InitSpec never went through
daemon/internal/rootless/specconv.ToRootless, so the /sys fix-up
for network=host under detach-netns (added in 84aedb805 "rootless:
support detach-netns mode") was skipped for plugins. This made
`docker plugin install` fail in rootless mode.
Apply the same rootless conversion that container specs receive in
daemon/oci_linux.go, gated on rootless.RunningWithRootlessKit().
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Fix an off-by-one error in isEqual() where the comparison loop started
at index 1 instead of 0, causing the first privilege (after sorting
alphabetically by name) to never be validated.
This allowed a malicious plugin to request different values for
whichever privilege sorts first — most notably "allow-all-devices",
which grants unrestricted rwm access to all host devices.
The bug also meant that plugins requesting exactly one privilege had
zero iterations of the comparison loop, bypassing validation entirely.
Also fix an existing test case ("diff-order-but-same-value") that only
passed due to the off-by-one bug, and add test cases for single-element
and first-sorted-element mismatches.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Updates docker pull to pull related attestation manifest and
any signatures for that manifest in cosign referrer objects.
These objects are transferred with the image when running
docker save and docker load and can be used to identify
the image in future updates.
Push is not updated atm as the currect push semantics
in containerd mode do not have correct immutability
guaranteed and don't work with image indexes.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
This type was used as Aux message for docker push, was not documented,
and only present for Docker Content Trust (which is deprecated).
This patch removes it from the API module, and moves the type internal.
We can stop sending this Aux message once DCT is fully phased out.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Move the progress package up into the client as a temporary shared location for
common clients like CLI and compose.
The progress package is used by the daemon to write progress updates to
some sink, typically a streamformatter. This package is of little use to
API clients as this package does not provide any facilities to consume
the progress updates.
Co-authored-by: Cory Snider <csnider@mirantis.com>
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
Most of the code in the filters package relates to the unmarshaling,
validation and application of filters from client requests. None of this
is necessary or particularly useful for Go SDK users. Move the full-fat
filters package into daemon/internal and switch all the daemon code to
import that package so we are free to iterate upon the code without
worrying about source-code interface compatibility.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The DockerVersion field was present for informational purposes, but was
not used anywhere. This patch stops propagating the field, which also
reduces the number of places where the `dockerversion` package is used,
which still needs a new home.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These utilities are very handy to use in integration tests, too. Move
the package so it can be imported by them.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The wire type of Plugin.Config.Interface.Types is an array of strings,
not of objects with three properties. We just so happen to have a Go
struct type to represent a plugin-interface-type value in memory with
all the fields parsed out for convenience, but that is not part of the
REST API contract documented by the Swager spec.U pdate the Swagger spec
to correctly document that the Types property is an array of strings in
the API, while still generating Go definitions that unmarshal into the
convenient struct type.
Move the definition and marshal/unmarshal methods for
PluginInterfaceType into a more appropriate location than api/types.
Rename the type to one that does not stutter or overload already
heavily overloaded terminology.
Modernize the parser and use property-based testing to assert that it
behaves the same as the old parser for all well-formed inputs.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The "backend" types in API were designed to decouple the API server
implementation from the daemon, or other parts of the code that
back the API server. This would allow the daemon to evolve (e.g.
functionality moved to different subsystems) without that impacting
the API server's implementation.
Now that the API server is no longer part of the API package (module),
there is no benefit to having it in the API module. The API server
may evolve (and require changes in the backend), which has no direct
relation with the API module (types, responses); the backend definition
is, however, coupled to the API server implementation.
It's worth noting that, while "technically" possible to use the API
server package, and implement an alternative backend implementation,
this has never been a prime objective. The backend definition was
never considered "stable", and we don't expect external users to
(attempt) to use it as such.
This patch moves the backend types to the daemon/server package,
so that they can evolve with the daemon and API server implementation
without that impacting the API module (which we intend to be stable,
following SemVer).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While it is imported by both the client and the daemon, values of the
PluginCreateOptions struct are not marshaled or unmarshaled. The only
field is mapped to and from an HTTP query parameter. Furthermore, this
options type is the odd one out: the daemon uses types in
api/types/backend to pass options around for the other plugin lifecycle
operations. Move the PluginCreateOptions type into client, and define a
new PluginCreateConfig struct in api/types/backend for the daemon to use
alongside PluginRmConfig, PluginEnableConfig and PluginDisableConfig.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The stringid package is used in many places; while it's trivial
to implement a similar utility, let's just provide it as a utility
package in the client, removing the daemon-specific logic.
For integration tests, I opted to use the implementation in the
client, as those should not ideally not make assumptions about
the daemon implementation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use the media-types defined in containerd, and create a local copy
of the media-type for plugins, which is not defined in either the
OCI or containerd package.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Paweł Gronowski