Compile the regular expression, instead of 'ad-hoc'. For this to work, I moved
the splitting was moved out of parseMountRaw() into ParseMountRaw(), and the
former was renamed to parseMount(). This function still receives the 'raw' string,
as it's used to include the "raw" spec for inclusion in error messages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add hints for "Failed to destroy btrfs snapshot <DIR> for <ID>: operation not permitted" on rootless
Related to issue 41762
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
`/containers/<name>/copy` endpoint was deprecated in 1.8 and errors
since 1.12. See https://github.com/moby/moby/pull/22149 for more info.
Signed-off-by: Roman Volosatovs <roman.volosatovs@docker.com>
(*PatternMatcher).Matches includes a special case for when the pattern
matches a parent dir, even though it doesn't match the current path.
However, it assumes that the parent dir which would match the pattern
must have the same number of separators as the pattern itself. This
doesn't hold true with a patern like "**/foo". A file foo/bar would have
len(parentPathDirs) == 1, which is less than the number of path
len(pattern.dirs) == 2... therefore this check would be skipped.
Given that "**/foo" matches "foo", I think it's a bug that the "parent
subdir matches" check is being skipped in this case.
It seems safer to loop over the parent subdirs and check each against
the pattern. It's possible there is a safe optimization to check only a
certain subset, but the existing logic seems unsafe.
Signed-off-by: Aaron Lehmann <alehmann@netflix.com>
Discovered a few instances, where loop variable is incorrectly used
within a test closure, which is marked as parallel.
Few of these were actually loops over singleton slices, therefore the issue
might not have surfaced there (yet), but it is good to fix there as
well, as this is an incorrect pattern used across different tests.
Signed-off-by: Roman Volosatovs <roman.volosatovs@docker.com>
The daemon uses a priority list to automatically select the best-matching storage
driver for the backing filesystem that is used.
Historically, overlay2 was not supported on Btrfs and ZFS, and the daemon would
automatically pick the `btrfs` or `zfs` storage driver if that was the Backing
File System.
Commits 649e4c8889 and e226aea280
improved our detection to check if overlay2 was supported on the backing file-
system, allowing overlay2 to be used on top of Btrfs or ZFS, but did not change
the priority list.
While both Btrfs and ZFS have advantages for certain use-cases, and provide
advanced features that are not available to overlay2, they also are known
to require more "handholding", and are generally considered to be mostly
useful for "advanced" users.
This patch changes the storage-driver priority list, to prefer overlay2 (if
supported by the backing filesystem), and effectively makes btrfs and zfs
opt-in storage drivers.
This change does not affect existing installations; the daemon will detect
the storage driver that was previously in use (based on the presence of
storage directories in `/var/lib/docker`).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When building the dev image, the Makefile generates a tag-name for the image,
based on the current git branch. As a result of this naming, old images will
collect on a developer's machine (especially when building from different
branches, for example when reviewing pull requests):
REPOSITORY TAG IMAGE ID CREATED SIZE
docker-dev HEAD 9785a8fb82f5 30 hours ago 2.13GB
docker-dev master 9785a8fb82f5 30 hours ago 2.13GB
docker-dev seccomp-closer-to-oci 9785a8fb82f5 30 hours ago 2.13GB
docker-dev move-stackdump 06882c142bfd 2 days ago 2.13GB
docker-dev add-dns-to-docker-info 2961ed1b99bd 10 days ago 2.13GB
docker-dev add-platform-info 2961ed1b99bd 10 days ago 2.13GB
docker-dev rata-seccomp-new-fields 2961ed1b99bd 10 days ago 2.13GB
docker-dev swagger-wip 2961ed1b99bd 10 days ago 2.13GB
docker-dev system-df-types 2961ed1b99bd 10 days ago 2.13GB
docker-dev use-oci-platform 2961ed1b99bd 10 days ago 2.13GB
docker-dev update-swagger-fork 3eeedecca85a 2 weeks ago 2.13GB
docker-dev remove-lcow-step5-alternative 51f9720bbc19 2 weeks ago 2.13GB
docker-dev update-s390x-ubuntu-2004 51f9720bbc19 2 weeks ago 2.13GB
docker-dev fix-image-shared-size 09e9aa46694a 2 weeks ago 2.13GB
docker-dev remove-discovery 11823223ae83 3 weeks ago 2.13GB
docker-dev daemon-config 355643e371b0 4 weeks ago 2.12GB
docker-dev jenkins-windows-containerd 68199214b860 4 weeks ago 2.11GB
docker-dev unfork-buildkit 68199214b860 4 weeks ago 2.11GB
docker-dev warn-on-non-matching-platform bc014b94017f 5 weeks ago 2.11GB
docker-dev remove-lcow 3a43c0900282 6 weeks ago 2.11GB
docker-dev remove-lcow-part5 3a43c0900282 6 weeks ago 2.11GB
docker-dev remove-lcow-step3 3a43c0900282 6 weeks ago 2.11GB
docker-dev remove-lcow-step4 3a43c0900282 6 weeks ago 2.11GB
docker-dev seccomp-unconfined-daemon 3a43c0900282 6 weeks ago 2.11GB
docker-dev update-authors 3a43c0900282 6 weeks ago 2.11GB
docker-dev payall4u-fix-creating-sandbox-when-disable-bridge 114c0f2ceb17 6 weeks ago 2.12GB
docker-dev catch-almost-all f437d2bc512b 8 weeks ago 2.12GB
docker-dev bin-criu c72894ae66f3 2 months ago 2.12GB
docker-dev bump-golang-1-14 395932141809 2 months ago 2.14GB
docker-dev upstream-systemd-units d0cb07f9473c 2 months ago 2.12GB
docker-dev bump-criu 6ed9e8fcf59f 2 months ago 2.12GB
This images are a bit of a pain to clean up, and because they are tagged,
`docker image prune` or `docker system prune` doesn't help (unless `--all` is
used).
Looking at the background of this naming, a found that it was originally added
in a95712899e, after a discussion on PR 3471.
At the time, the image name was used to check if the image needed building, and
otherwise building was skipped in the makefile.
This is no longer the case; the image is built unconditionally, and the build-
cache helps (where possible) speed up rebuilding the image.
In _theory_ having unique names would allow for multiple dev containers (from
different branches) to be started in parallel, but in most situations, the
source-code will be mounted (`BIND_MOUNT=.`), so I'm not sure if that should
be a compelling reason to keep the current naming.
This patch removes the unique tag, and will always tag the image locally as
`docker-dev:latest`.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch, similar to d92739713c, embeds the
`LinuxSeccomp` type of the runtime-spec, so that we can support all options
provided by the spec, and decorates it with our own fields.
With this, profiles can make use of the recently added "Flags" field, to
specify flags that must be passed to seccomp(2) when installing the filter.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Make the error message slightly more informative, and remove the redundant
`len(config.ArchMap) != 0` check, as iterating over an empty, or 'nil' slice
is a no-op already. This allows to use a slightly more idiomatic "if ok := xx; ok"
condition.
Also move validation to the start of the loop (early return), and explicitly create
a new slice for "names" if the legacy "Name" field is used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add test to verify profile validation, and to verify that the legacy
format actually loads the profile as expected (instead of only verifying
it doesn't produce an error).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's the only location where this is used, and it's quite specific
to dockerd (not really a reusable function for external use), so
moving it into that package.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It is not directly related to signal-handling, so can well live
in its own package.
Also added a variant that doesn't take a directory to write files
to, for easier consumption / better match to how it's used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The "quiet" argument was only used in a single place (at daemon startup), and
every other use had to pass "false" to prevent this function from logging
warnings.
Now that SysInfo contains the warnings that occurred when collecting the
system information, we can make leave it up to the caller to use those
warnings (and log them if wanted).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
