Make sure to ignore local {container,docker}ignore files when building a
local pause image. Otherwise, we may mistakenly not be able to copy
catatonit into the build container.
Fixes: #13529
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
When podman generate systemd is invoked, it previously did not check if
container-prefix or pod-prefix are empty. When these are empty, the file name
starts with the separator, which is hyphen by default. This results in files
like '-containername.service'.
The code now checks if these prefixes are empty. If they are, the filename no
longer adds a separator. Instead, it uses name or ID of the container or pod.
Closes#13272
Signed-off-by: Nirmal Patel <npate012@gmail.com>
The permissions on disk were wrong since we were not converting to
octal.
Fixes: https://github.com/containers/podman/issues/13108
[NO NEW TESTS NEEDED] Since we don't currently test using the docker
client
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
pprof tests are way too flaky, and are causing problems for
community contributors who don't have privs to press Re-run.
There has been no activity or interest in fixing the bug,
and it's not something I can fix. So, just disable the test.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Secret-verify-leak is causing flakes, when running in parallel tests.
This is because remote secrets are copied into the context directory to
send to the API server, and secret-verify-leak is doing a COPY * and
then checking if the temporary secret file ends up in the container or
not. Since all the temporary files are prefixed with
"podman-build-secret", this test checks if podman-build-secret is in the
image. However, when run in parallel with other tests, other temporary
podman-build-secrets might be in the context dir. Moving
secret-verify-leak into its own directory makes sure that the context
dir is used only by this one test.
Also renamed Dockerfile -> Containerfile and cleaned up unused
Containerfiles.
Signed-off-by: Ashley Cui <acui@redhat.com>
Error out if the kube yaml passed to play kube has more
than one container or init container with the same name.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
do not attempt to use cgroups with pods if the cgroups are disabled.
A similar check is already in place for containers.
Closes: https://github.com/containers/podman/issues/13411
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
While resolving `workdir` we mostly create a `workdir` when `stat`
fails with `ENOENT` or `ErrNotExist` however following cases are not
true when user explicitly specifies a `workdir` while `running` using
`--workdir` which tells `podman` to only use workdir if its exists on
the container. Following configuration is implicity set with other
`run` mechanism like `podman play kube`
Problem with explicit `--workdir` or similar implicit config in `podman play
kube` is that currently podman ignores the fact that workdir can also be
a `symlink` and actual `link` could be valid.
Hence following commit ensures that in such scenarios when a `workdir`
is not found and we cannot create a `workdir` podman must perform a
check to ensure that if `workdir` is a `symlink` and `link` is resolved
successfully and resolved link is present on the container then we
return as it is.
Docker performs a similar behviour.
Signed-off-by: Aditya R <arajan@redhat.com>
The kernel never sets the inheritable capabilities for a process, they
are only set by userspace. Emulate the same behavior.
Closes: CVE-2022-27649
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
(cherry picked from commit aafa80918a)
Invoking parallel/concurrent builds from podman race against each other
following behviour was fixed in
containers/storage#1153 and containers/image#1480
Test verifies if following bug is fixed in new race-free API or not.
Read more about this issue, see bz 2055487 for more details.
Test manually backported from: containers@63f92d0
Signed-off-by: Aditya R <arajan@redhat.com>
Update the login tests to reflect the latest changes to allow http{s}
prefixes (again) to address bugzilla.redhat.com/show_bug.cgi?id=2062072.
Backport of commit 57cdc21b00.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Backports: #13421 Set default rule at the head of device configuration
by @hshiina
The default rule should be set at the head of device configuration.
Otherwise, rules for user devices are overridden by the default rule so
that any access to the user devices are denied.
This has been requested to backport and to include in RHEL 8.6 and 9.0.
The exception process is underway.
Addresses these BZs for the backport:
https://bugzilla.redhat.com/show_bug.cgi?id=2059296https://bugzilla.redhat.com/show_bug.cgi?id=2062835
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
We could remove the container running the volume plugins, before
the containers using the volume plugins; this could cause
unmounting the volumes to fail because the plugin could not be
contacted.
Signed-off-by: Matthew Heon <mheon@redhat.com>
The CONTAINERS_CONF environment variable can be used to override the
configuration file, which is useful for testing. However, at the moment
this variable is not propagated to conmon. That means in particular, that
conmon can't propagate it back to podman when invoking its --exit-command.
The mismatch in configuration between the starting and cleaning up podman
instances can cause a variety of errors.
This patch also adds two related test cases. One checks explicitly that
the correct CONTAINERS_CONF value appears in conmon's environment. The
other checks for a possible specific impact of this bug: if we use a
nonstandard name for the runtime (even if its path is just a regular crun),
then the podman container cleanup invoked at container exit will fail.
That has the effect of meaning that a container started with -d --rm won't
be correctly removed once complete.
Fixes#12917
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This comment refers to overiding $PODMAN although the code below does
nothing of the sort. Presumbly the comment has been outdated by altering
the containers.conf / $CONTAINERS_CONF instead.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We're running into problems that are impossible to diagnose
because we have no idea if the SUT is using netavark or CNI.
We've previously run into similar problems with runc/crun,
or cgroups 1/2.
This adds a one-line 'echo' with important system info. Now,
when viewing a full test log, it will be possible to view
system settings in one glance.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Add a extra `See 'podman command --help'` to the error output.
With this patch you now get:
```
$ podman run -h
Error: flag needs an argument: 'h' in -h
See 'podman run --help'
```
Fixes#13082Fixes#13002
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
`podman play kube` tries to build images even if `--build` is set to
false so lets honor that and make `--build` , `true` by default so it
matches the original behviour.
Signed-off-by: Aditya R <arajan@redhat.com>
When a test which creates a network fail it will not remove the network.
The teardown logic should remove the networks. Since there is no --all
option for network rm we use network prune --force.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When removing a container created with a --volumes-from a container
created with a built in volume, we complain if the original container
still exists. Since this is an expected state, we should not complain
about it.
Fixes: https://github.com/containers/podman/issues/12808
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Checkpoint/restore pod tests are not running with an older runc and now
that runc 1.1.0 appears in the repositories it was detected that the
tests were failing. This was not detected in CI as CI was not using runc
1.1.0 yet.
Signed-off-by: Adrian Reber <areber@redhat.com>
For the since and after imagve filter tests, instead of using the
read-only cache of images, we just use the empty r/w store. We then
build three images that are strictly predictable.
Signed-off-by: Brent Baude <bbaude@redhat.com>
It looks like some descriptions have changed on the docker registry
where we had been searching for images that include 'alpine'. We are
now seeing an image in the initial list that has 'alpine' in its
description.
Signed-off-by: Brent Baude <bbaude@redhat.com>
The `podman network connect` and `podman network disconnect`
commands give containers access to different networks than the
ones they were created with; these networks can also have DNS
servers associated with them. Until now, however, we did not
modify resolv.conf as network membership changed.
With this PR, `podman network connect` will add any new
nameservers supported by the new network to the container's
/etc/resolv.conf, and `podman network disconnect` command will do
the opposite, removing the network's nameservers from
`/etc/resolv.conf`.
Fixes#9603
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
When running podman inside systemd user units, it is possible that
systemd kills the rootless netns slirp4netns process because it was
started in the default unit cgroup. When the unit is stopped all
processes in that cgroup are killed. Since the slirp4netns process is
run once for all containers it should not be killed. To make sure
systemd will not kill the process we move it to the user.slice.
Fixes#13153
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Lot of clients are expecting proper `Content-type: application/json`
configured in response headers of `/build` compat api. Following commit
fixes that.
Fixes issues where code is setting header field after writing header
which is wrong. We must set `content-type` before we write and flush
http header.
Signed-off-by: Aditya R <arajan@redhat.com>
All the healthcheck return output now but systems tests is written to
expect empty output which seems wrong.
Modify jq output to contain newline character rather than actual newline
Signed-off-by: Aditya R <arajan@redhat.com>
It seems we are ignoring output from healthcheck session.
Open a valid pipe to healthcheck session in order read its output.
Use common pipe for both `stdout/stderr` since that was the previous
behviour as well.
Signed-off-by: Aditya R <arajan@redhat.com>
Append the podman dns seach domain to the host search domains when we
use the dnsname/aardvark server. Previously it would only use podman
seach domains and discard the host domains.
Fixes#13103
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
separated cgroupNS sharing from setting the pod as the cgroup parent,
made a new flag --share-parent which sets the pod as the cgroup parent for all
containers entering the pod
remove cgroup from the default kernel namespaces since we want the same default behavior as before which is just the cgroup parent.
resolves#12765
Signed-off-by: cdoern <cdoern@redhat.com>
Signed-off-by: cdoern <cbdoer23@g.holycross.edu>
Signed-off-by: cdoern <cdoern@redhat.com>
* Ensure meaningful behaviour when called with /v3.x.x semantics
* Change return code to 409 from 500 when client attempts to use an
existing network name
* Update API bats test runner to support /v4.0.0 endpoints by default
Signed-off-by: Jhon Honce <jhonce@redhat.com>
This reverts commit a1bc8cb52c.
Please see resolv.conf(5) search domains must be on the same line. If
you use multiple seach key words only the last one is used. I tested this
with alpine and it works correctly when they are on the same line so I
am not sure what issues Dan had with it but this is not correct.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Alpine does not seem to use search correctly when there are multiple
search domains on the same line. It only uses the first with the advent.
When podman runs within a separate network we are appending on
dns.podman as a search, if you add a search domain, then this causes the
local search on network to fail.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
podman system prune should also remove all networks. When we want to
users to migrate to the new network stack we recommend to run podman
system reset. However this did not remove networks and if there were
still networks around we would continue to use cni since this was
considered an old system.
There is one exception for the default network. It should not be removed
since this could cause other issues when it no longer exists. The
network backend detection logic ignores the default network so this is
fine.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
