When you execute podman create/run with the --pod new:<name> syntax
the pod was created but the namespaces where not shared and
therefore containers could not communicate over localhost.
Add the default namespaces and pass the network options to the
pod create options.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
when setting up the user namespace do not ignore errors from
newuidmap/newgidmap if there are mappings configured.
The single user mapping is a fallback only when there are not mappings
specified for the user.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
The initial version of the new port code mistakenly restricted
this, so un-restrict it. We still need to maintain the map of
container ports, unfortunately (need to verify if the port in
question is a duplicate, for example).
Fixes#7062
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
We are returning bogus data in podman-remote images --format json.
This change will match the same data returned my podman images --format json.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The "podman wait to pause|unpause condition" test is failing
several times a day, always a flake. Issue #6518.
Disable it until the cause can be identified and fixed.
Signed-off-by: Ed Santiago <santiago@redhat.com>
`podman image search` returned wrong results for the image "Description" as
it was mapped to the wrong field ("ID") in the search results.
Signed-off-by: Ralf Haferkamp <rhafer@suse.com>
There are many use cases where you want to just mount an image
without creating a container on it. For example you might want
to just examine the content in an image after you pull it for
security analysys. Or you might want to just use the executables
on the image without running it in a container.
The image is mounted readonly since we do not want people changing
images.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We should default to the user name unmount rather then the internal
name of umount.
Also User namespace was not being handled correctly. We want to inform
the user that if they do a mount when in rootless mode that they have
to be first in the podman unshare state.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The v2.0 reference [page](http://docs.podman.io/en/latest/Reference.html)
lists the API as experimental. Removed that word and reworked the first
paragraph a bit based on verbiage that @mheon put together for the
API intro blog.
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
Currently you can not apply an ApparmorProfile if you specify
--privileged. This patch will allow both to be specified
simultaniosly.
By default Apparmor should be disabled if the user
specifies --privileged, but if the user specifies --security apparmor:PROFILE,
with --privileged, we should do both.
Added e2e run_apparmor_test.go
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
--umask sets the umask inside the container
Defaults to 0022
Co-authored-by: Daniel J Walsh <dwalsh@redhat.com>
Signed-off-by: Ashley Cui <acui@redhat.com>
The versions Docker that the compat endpoints currently support are
using another type for the `filters` parameter than later versions
of Docker, which the libpod/events endpoint is also using.
To prevent existing deplopyments from breaking while still achieving
backward compat, we now support both types for the filters parameter.
Tested manually.
Fixes: #6899
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Fix a potential panic in the events endpoint when parsing the filters
parameter. Values of the filters map might be empty, so we need to
account for that instead of uncondtitionally accessing the first item.
Also apply a similar for race conditions as done in commit f4a2d25c0f:
Fix a race that could cause read errors to be masked. Masking
such errors is likely to report red herrings since users don't
see that reading failed for some reasons but that a given event
could not be found.
Another race was the handler closing event channel, which could lead to
two kinds of panics: double close, send to close channel. The backend
takes care of that. However, make sure that the backend stops working
in case the context has been cancelled.
Fixes: #6899
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
When an image has no name/tag system df will
error because it tries to parse an empty name.
This commit makes sure we only parse non
empty names and set the repository and tag
to "<none>" otherwise.
Closes#7015
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
This matches Docker behavior, and will make the Docker frontend
work with `podman system service` (Docker tries to create, then
if that fails with 404 sends a request to pull the image).
Fixes#6960
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Podman is committed to inclusivity, a core value of open source. Historically, there have been technology terms that are problematic and divisive, and should be changed. We are currently taking time to audit our repository in order to eliminate such terminology, and replace it with more inclusive terms. We are starting where we can, with our own code, comments, and documentation. However, such terms may be used in dependencies, and must be used in our repositories at the current moment for compatibility. Podman will change these terms in our repo as soon as new and better terminology is available to us via our dependencies.
For more information: https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language?sc_cid=701600000011gf0AAA
Signed-off-by: Ashley Cui <acui@redhat.com>
When creating a pod or container where a static MAC or IP address is provided, we should return a proper error and exit as 125.
Fixes: #6972
Signed-off-by: Brent Baude <bbaude@redhat.com>
As of podman 1.8.0, because of commit da7595a, the default approach of providing
port-forwarding in rootless mode has switched (and been hard-coded) to rootlessport,
for the purpose of providing super performance. The side-effect of this switch is
source within the container to the port-forwarded service always appears to originate
from 127.0.0.1 (see issue #5138).
This commit allows a user to specify if they want to revert to the previous approach
of leveraging slirp4netns add_hostfwd() api which, although not as stellar performance,
restores usefulness of seeing incoming traffic origin IP addresses.
The change should be transparent; when not specified, rootlessport will continue to be
used, however if specifying --net slirp4netns:slirplisten the old approach will be used.
Note: the above may imply the restored port-forwarding via slirp4netns is not as
performant as the new rootlessport approach, however the figures shared in the original
commit that introduced rootlessport are as follows:
slirp4netns: 8.3 Gbps,
RootlessKit: 27.3 Gbps,
which are more than sufficient for many use cases where the origin of traffic is more
important than limits that cannot be reached due to bottlenecks elsewhere.
Signed-off-by: Aleks Mariusz <m.k@alek.cx>
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This change prevents this exception when loading a pod spec
using the "IfNotPresent" pull policy:
Error: invalid pull type "IfNotPresent"
Signed-off-by: Tristan Cacqueray <tdecacqu@redhat.com>
We were only using the Command field in specgen when determining
whether to enable systemd if systemd=true (the default) was used.
This does not include the entrypoint, and does not include any
entrypoint/command sourced from the image - so an image could be
running systemd and we'd not correctly detect this. Using the
full, final command resolves this and matches Podman v1.9.x
behavior.
Fixes#6920
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
