Looks like vndr didn't like the replace rule missing a scheme;
github.com/docker/distribution: Err: exit status 128, out: fatal: repository 'github.com/samuelkarp/docker-distribution' does not exist
github.com/containerd/containerd: Err: exit status 128, out: fatal: repository 'github.com/moby/containerd' does not exist
While at it, I also replaced the schem for go-immutable-radix, because GitHub
is deprecating the git:// protocol.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The twelfth patch release for containerd 1.4 contains a few minor bug fixes
and an update to mitigate CVE-2021-41190.
Notable Updates
* Handle ambiguous OCI manifest parsing GHSA-5j5w-g665-5m35
* Update pull to try next mirror for non-404 errors
* Update pull to handle of non-https urls in descriptors
See the changelog for complete list of changes
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
imageutil: make mediatype detection more stricter to mitigate CVE-2021-41190.
full diff: 244e8cde63...bc07b2b81b
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This should help with Jenkins failing to clean up the Workspace:
- make sure "cleanup" is also called in the defer for all daemons. keeping
the daemon's storage around prevented Jenkins from cleaning up.
- close client connections and some readers (just to be sure)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit eea2758761)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The storage-driver directory caused Jenkins cleanup to fail. While at it, also
removing other directories that we do not include in the "bundles" that are
stored as Jenkins artifacts.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 1a15a1a061)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.16.10 (released 2021-11-04) includes security fixes to the archive/zip and
debug/macho packages, as well as bug fixes to the compiler, linker, runtime, the
misc/wasm directory, and to the net/http package. See the Go 1.16.10 milestone
for details: https://github.com/golang/go/issues?q=milestone%3AGo1.16.10+label%3ACherryPickApproved
From the announcement e-mail:
[security] Go 1.17.3 and Go 1.16.10 are released
We have just released Go versions 1.17.3 and 1.16.10, minor point releases.
These minor releases include two security fixes following the security policy:
- archive/zip: don't panic on (*Reader).Open
Reader.Open (the API implementing io/fs.FS introduced in Go 1.16) can be made
to panic by an attacker providing either a crafted ZIP archive containing
completely invalid names or an empty filename argument.
Thank you to Colin Arnott, SiteHost and Noah Santschi-Cooney, Sourcegraph Code
Intelligence Team for reporting this issue. This is CVE-2021-41772 and Go issue
golang.org/issue/48085.
- debug/macho: invalid dynamic symbol table command can cause panic
Malformed binaries parsed using Open or OpenFat can cause a panic when calling
ImportedSymbols, due to an out-of-bounds slice operation.
Thanks to Burak Çarıkçı - Yunus Yıldırım (CT-Zer0 Crypttech) for reporting this
issue. This is CVE-2021-41771 and Go issue golang.org/issue/48990.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Looks like this test was broken from the start, and fully relied on a race
condition. (Test was added in 65ee7fff02)
The problem is in the service's command: `ls -l /etc/config || /bin/top`, which
will either:
- exit immediately if the secret is mounted correctly at `/etc/config` (which it should)
- keep running with `/bin/top` if the above failed
After the service is created, the test enters a race-condition, checking for 1
task to be running (which it ocassionally is), after which it proceeds, and looks
up the list of tasks of the service, to get the log output of `ls -l /etc/config`.
This is another race: first of all, the original filter for that task lookup did
not filter by `running`, so it would pick "any" task of the service (either failed,
running, or "completed" (successfully exited) tasks).
In the meantime though, SwarmKit kept reconciling the service, and creating new
tasks, so even if the test was able to get the ID of the correct task, that task
may already have been exited, and removed (task-limit is 5 by default), so only
if the test was "lucky", it would be able to get the logs, but of course, chances
were likely that it would be "too late", and the task already gone.
The problem can be easily reproduced when running the steps manually:
echo 'CONFIG' | docker config create myconfig -
docker service create --config source=myconfig,target=/etc/config,mode=0777 --name myservice busybox sh -c 'ls -l /etc/config || /bin/top'
The above creates the service, but it keeps retrying, because each task exits
immediately (followed by SwarmKit reconciling and starting a new task);
mjntpfkkyuuc1dpay4h00c4oo
overall progress: 0 out of 1 tasks
1/1: ready [======================================> ]
verify: Detected task failure
^COperation continuing in background.
Use `docker service ps mjntpfkkyuuc1dpay4h00c4oo` to check progress.
And checking the tasks for the service reveals that tasks exit cleanly (no error),
but _do exit_, so swarm just keeps up reconciling, and spinning up new tasks;
docker service ps myservice --no-trunc
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
2wmcuv4vffnet8nybg3he4v9n myservice.1 busybox:latest@sha256:f7ca5a32c10d51aeda3b4d01c61c6061f497893d7f6628b92f822f7117182a57 docker-desktop Ready Ready less than a second ago
5p8b006uec125iq2892lxay64 \_ myservice.1 busybox:latest@sha256:f7ca5a32c10d51aeda3b4d01c61c6061f497893d7f6628b92f822f7117182a57 docker-desktop Shutdown Complete less than a second ago
k8lpsvlak4b3nil0zfkexw61p \_ myservice.1 busybox:latest@sha256:f7ca5a32c10d51aeda3b4d01c61c6061f497893d7f6628b92f822f7117182a57 docker-desktop Shutdown Complete 6 seconds ago
vsunl5pi7e2n9ol3p89kvj6pn \_ myservice.1 busybox:latest@sha256:f7ca5a32c10d51aeda3b4d01c61c6061f497893d7f6628b92f822f7117182a57 docker-desktop Shutdown Complete 11 seconds ago
orxl8b6kt2l6dfznzzd4lij4s \_ myservice.1 busybox:latest@sha256:f7ca5a32c10d51aeda3b4d01c61c6061f497893d7f6628b92f822f7117182a57 docker-desktop Shutdown Complete 17 seconds ago
This patch changes the service's command to `sleep`, so that a successful task
(after successfully performing `ls -l /etc/config`) continues to be running until
the service is deleted. With that change, the service should (usually) reconcile
immediately, which removes the race condition, and should also make it faster :)
This patch changes the tests to use client.ServiceLogs() instead of using the
service's tasklist to directly access container logs. This should also fix some
failures that happened if some tasks failed to start before reconciling, in which
case client.TaskList() (with the current filters), could return more tasks than
anticipated (as it also contained the exited tasks);
=== RUN TestCreateServiceSecretFileMode
create_test.go:291: assertion failed: 2 (int) != 1 (int)
--- FAIL: TestCreateServiceSecretFileMode (7.88s)
=== RUN TestCreateServiceConfigFileMode
create_test.go:355: assertion failed: 2 (int) != 1 (int)
--- FAIL: TestCreateServiceConfigFileMode (7.87s)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 13cff6d583)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this change if you assume that things work the way the test
expects them to (it does not, but lets assume for now) we aren't really
testing anything because we are testing that a container is healthy
before and after we send a signal. This will give false positives even
if there is a bug in the underlying code. Sending a signal can take any
amount of time to cause a container to exit or to trigger healthchecks
to stop or whatever.
Now lets remove the assumption that things are working as expected,
because they are not.
In this case, `top` (which is what is running in the container) is
actually exiting when it receives `USR1`.
This totally invalidates the test.
We need more control and knowledge as to what is happening in the
container to properly test this.
This change introduces a custom script which traps `USR1` and flips the
health status each time the signal is received.
We then send the signal twice so that we know the change has occurred
and check that the value has flipped so that we know the change has
actually occurred.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 27ba755f70)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Starting `dockerd-rootless.sh` checks that `$HOME` is writeable, but does not
require it to be so.
Make the check more precise, and check that it actually exists and is a
directory.
Signed-off-by: Hugo Osvaldo Barrera <hugo@barrera.io>
(cherry picked from commit 3980d0462d)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
log statement should reflect how long it actually waited, not how long
it theoretically could wait based on the 'seconds' integer passed in.
Signed-off-by: Cam <gh@sparr.email>
(cherry picked from commit d15ce134ef)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
this refactors the Stop command to fix a few issues and behaviors that
dont seem completely correct:
1. first it fixes a situation where stop could hang forever (#41579)
2. fixes a behavior where if sending the
stop signal failed, then the code directly sends a -9 signal. If that
fails, it returns without waiting for the process to exit or going
through the full docker kill codepath.
3. fixes a behavior where if sending the stop signal failed, then the
code sends a -9 signal. If that succeeds, then we still go through the
same stop waiting process, and may even go through the docker kill path
again, even though we've already sent a -9.
4. fixes a behavior where the code would wait the full 30 seconds after
sending a stop signal, even if we already know the stop signal failed.
fixes#41579
Signed-off-by: Cam <gh@sparr.email>
(cherry picked from commit 8e362b75cb)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
1. fixes#41587
2. removes potential infinite Wait and goroutine leak at end of kill
function
fixes#41587
Signed-off-by: Cam <gh@sparr.email>
(cherry picked from commit e57a365ab1)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Updates go-winio to the latest v0.4.x version. The main important fix
here is to go-winio's backuptar package. This is needed to fix a bug in
sparse file handling in container layers, which was exposed by a recent
change in Windows.
go-winio v0.4.20: https://github.com/microsoft/go-winio/releases/tag/v0.4.20
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
go1.16.9 (released 2021-10-07) includes a security fix to the linker and misc/wasm
directory, as well as bug fixes to the runtime and to the text/template package.
See the Go 1.16.9 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.16.9+label%3ACherryPickApproved
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The eleventh patch release for containerd 1.4 is a security release to fix CVE-2021-41103.
Notable Updates
- Fix insufficiently restricted permissions on container root and plugin directories GHSA-c2h3-6mxw-7mvq
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Update runc to v1.0.2
- Update hcsshim to v0.8.21
- Support "clone3" in default seccomp profile
- Fix panic in metadata content writer on copy error
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is to allow quota package (without tests) to be built without cgo.
makeBackingFsDev was used in helpers but not defined in projectquota_unsupported.go
Also adjust some GoDoc to follow the standard format.
Signed-off-by: Tibor Vass <tibor@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 7cf079acdb)
Signed-off-by: Pete Woods <pete.woods@circleci.com>
This includes additional fixes for CVE-2021-39293.
go1.16.8 (released 2021-09-09) includes a security fix to the archive/zip package,
as well as bug fixes to the archive/zip, go/internal/gccgoimporter, html/template,
net/http, and runtime/pprof packages. See the Go 1.16.8 milestone on the issue
tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.16.8+label%3ACherryPickApproved
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is a backport of 9f6b562dd1, adapted to avoid the refactoring that happened in d92739713c.
Original commit message is as follows:
> If no seccomp policy is requested, then the built-in default policy in
> dockerd applies. This has no rule for "clone3" defined, nor any default
> errno defined. So when runc receives the config it attempts to determine
> a default errno, using logic defined in its commit:
>
> opencontainers/runc@7a8d716
>
> As explained in the above commit message, runc uses a heuristic to
> decide which errno to return by default:
>
> [quote]
> The solution applied here is to prepend a "stub" filter which returns
> -ENOSYS if the requested syscall has a larger syscall number than any
> syscall mentioned in the filter. The reason for this specific rule is
> that syscall numbers are (roughly) allocated sequentially and thus newer
> syscalls will (usually) have a larger syscall number -- thus causing our
> filters to produce -ENOSYS if the filter was written before the syscall
> existed.
> [/quote]
>
> Unfortunately clone3 appears to one of the edge cases that does not
> result in use of ENOSYS, instead ending up with the historical EPERM
> errno.
>
> Latest glibc (2.33.9000, in Fedora 35 rawhide) will attempt to use
> clone3 by default. If it sees ENOSYS then it will automatically
> fallback to using clone. Any other errno is treated as a fatal
> error. Thus when docker seccomp policy triggers EPERM from clone3,
> no fallback occurs and programs are thus unable to spawn threads.
>
> The clone3 syscall is much more complicated than clone, most notably its
> flags are not exposed as a directly argument any more. Instead they are
> hidden inside a struct. This means that seccomp filters are unable to
> apply policy based on values seen in flags. Thus we can't directly
> replicate the current "clone" filtering for "clone3". We can at least
> ensure "clone3" returns ENOSYS errno, to trigger fallback to "clone"
> at which point we can filter on flags.
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
Co-authored-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
(cherry picked from commit 14189170d1)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
(cherry picked from commit 1a67e9572e)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
