This is a long standing flake but I see it again in the lima CI, the
problem seems to happen when we stop the container before the background
healthcheck fires.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 90ba6562d5)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In highly parallel runs this can fail its timeout due the fact that we
run podman ps -a which takes all contianer locks, even the ones from
unrelated tests. thus this command can take a long time, from a CI log I
see:
[18:22:30.932958589] # /var/tmp/podman/bin/podman ps -a
[18:22:34.338904713] CONTAINER ID IMAGE
So like a 4s delay just on that and hence the test later failed with
"Operations took too long" as it took 7 seconds overall.
So since we know podman inspect takes the lock just keep that and not
try to get all containers for no reason.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 34137c40f6)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This seems to flake in the parallel CI runs as another process might
also use 8080 already.
We can use any port here so use GetPort() which should give us a
conflict free one.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 472c53b122)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
I saw this already in openQA and now with the new rawhide images we hit
it in upstream as well. Skip this for now to not cause so many flakes.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 0dbe00d272)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This is really not nice but it is a quick fix to avoid more flakes.
The 10.11.12.0/24 was used by several tests and podman will only allow
the network to be created once with a given subnet so we need to ensure
they are conflict free, otherwise in parallel runs they will fail
randomly.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 97d0279e94)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The container prints "Failed to set RLIMIT_CORE: Operation not permitted"
I do not know why this fails when run with sudo but lets just skip it it
for now.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 07e257e7f6)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The test assumes a local id_ed25519 ssh key exists and is setup to
connect to its own user. That is basically never the case locally so the
test is broken by design.
If the test should run in some special CI setup where that is the case
we need to enable it and guard based on that later.
For now I just like to get the lima VM tests passing.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 1de60ebf7b)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The test assumed /home/$USER == $HOME which may not be the case. In fact
it is not the case in the new lima VM runners.
Fix the test to actually use the path we want to test for, $HOME.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 39ee9baf66)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
It is not working in all ipv6 setups. In the new lima testing env
default_addr is just null causing the test to fail because the container
address was "fec0::5055:55ff:fe2b:6cc9".
For now skip this until we can figure something better out.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 9aca6010ee)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
As found in fedora openQA testing on the kernel update this test fails
due a selinux denial.
The kernel now correctly checks the backing fs selinux context in all
cases. See kernel commit 82544d36b172 (selinux: fix overlayfs mmap()
and mprotect() access checks).
The test tries to access another container so the selinux level will
be different from the quadlet roofs container and therefore fail to
access the files.
To fix this we should be able to just use the regular image mount which
has a level all containers can access. The comment that this is not
parallel safe is untrue, mounts are reference counted so this should not
get unmounted all of the sudden by another test.
In fact we have another --rootfs test case where we do this and it
passed in openQA, see "podman run - check workdir".
Fixes: #28602
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 12d40777f0)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
To avoid special chars from being interpreted.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 571c842bd3)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Bump the timeout to 60 minutes. We already bumped to 40 minutes a while
ago in commit 623cb5f but it seems this is not enough.
The x86_64 test needs only 25 minutes so I am confused why aarch64 got
so much slower, they used to be around the same time.
Of course our tests should not take that long so we really need to
figure out what is actually causing this slow down.
Looking at logs a test that boots and stops a VM takes 30s on x86_64
while it takes 50s on aarch64.
However at the same time the aarch64 test on the macs with libkrun and
applehv are quite fast (15-17m) so it seems unlikely to me that it is
something inside the aarch64 machine image that causes but rather
related to the host side.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 938d677ad9)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The server already does validate this so this is not strictly needed and
the client must trust the server no matter what.
But adding an extra check here does not hurt and may help prevent future
bugs.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 12bec19426)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Just as additional hardening.
Note chrootarchive does not work on macos/windows, in that case it still
falls back to the regular pkg/archive.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 25aee24cbd)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Under normal circumstances this is not a problem as the archive file
created podman container checkpoint will no create symlinks.
However if a user passes a custom archive they could contain symlinks
that point outside our root. To resolve them within the root use
securejoin.
Note this is not a security problem because the full archive must be
trusted by a user to begin with as it contain the full container config.
Fixes: #27977
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit abb5120624)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The go std os package to will always make sure to use O_CLOEXEC, however
in cases where we directly call unix.Open() we need to pass that flag
explicitly.
I looked at this as there was a report of a leaked fd on the pasta list,
though I am not sure this will address it.
But anyway doing this should be rather safe and avoid leaks into other
processes.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit d20933df02)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Verify that creating a secret with driver=shell and no --driver-opts
does not inherit the file driver's default path option. Before the fix,
this produced "invalid shell driver option"; after, it correctly fails
with "missing config value" for unconfigured shell commands.
Signed-off-by: Joe Doss <joe@solidadmin.com>
(cherry picked from commit 8b905613b5)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When creating a secret with driver=shell via the API, the file driver's
default DriverOpts (including path) were applied because DriverOpts was
empty. The shell driver rejects path as an unknown option, making it
impossible to create shell-driver secrets via the REST API or
podman-remote.
Only apply default DriverOpts from config when the requested driver
matches the configured default driver.
Signed-off-by: Joe Doss <joe@solidadmin.com>
(cherry picked from commit 667f55c2ce)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
ExecContainerHTTP returns attachChan to its caller before attachExecHTTP
finishes. The caller's deferred close(holdConnOpen) can therefore fire
while attachExecHTTP is still running (including its own deferred
cleanups), which races with the goroutine inside attachExecHTTP that
reads deferredErr after <-holdConnOpen unblocks.
Fix this by introducing an errCh channel: deferred functions write
deferredErr into it, and the goroutine reads from it after
<-holdConnOpen unblocks, ensuring the read happens-after all writes to
the named return value.
Fixes: #28277
Signed-off-by: crawfordxx <crawfordxx@users.noreply.github.com>
(cherry picked from commit 497185c14b)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When `podman-remote` tars the context, extra `podman-build-secret*` paths were
either dropped by `.dockerignore` (#25314) or archived as absolute paths so
`COPY . .` pulled host-shaped trees into the image (#28334).
Use relative names under the primary context for extra sources and do not apply
`.dockerignore` to those forced entries.
Fixes: https://github.com/containers/podman/issues/25314
Fixes: https://github.com/containers/podman/issues/28334
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
(cherry picked from commit e18bb9ea8b)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In the SystemCheck HTTP handler, when parsing the
unreferenced_layer_max_age query parameter fails, the error response is
sent but execution continues to `unreferencedLayerMaximumAge = &duration`
where `duration` is the zero value. This causes the system check to run
with a zero duration instead of returning the 400 error to the client.
Add the missing `return` after the error response.
Fixes#28350
Signed-off-by: crawfordxx <crawfordxx@users.noreply.github.com>
(cherry picked from commit 29d80a26af)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Podman uses this env toi do various things, we don't want the external
env to affect our tests here.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
(cherry picked from commit 7e3caaed84)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This prevents a nil pointer crash when running network=host containers
on a FreeBSD host using podman-remote.
Fixes: #28289
Signed-off-by: Doug Rabson <dfr@rabson.org>
(cherry picked from commit 9a10cefd18)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Setting Entrypoint= (empty value) in a quadlet .container file should
produce --entrypoint "" in the generated podman command, which clears
the image's default entrypoint. Previously this was silently ignored
because lookupAndAddString skips empty values.
Move the Entrypoint key out of the generic stringKeys map and handle
it separately so that an empty value is passed through.
Closes#28213
Signed-off-by: umut-polat <52835619+umut-polat@users.noreply.github.com>
(cherry picked from commit 926f562bd5)
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
