do not set the cgroup parent when running as rootless with cgroupfs,
even if cgroup v2 is used.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1947999
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Docker does not relabel this content, and openstack is running
containers in this manner. There is a penalty for doing this
on each container, that is not worth taking on a disable SELinux
container.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Instead of creating an extra container create a network and mount
namespace inside the podman user namespace. This ns is used to
for rootless cni operations.
This helps to align the rootless and rootful network code path.
If we run as rootless we just have to set up a extra net ns and
initialize slirp4netns in it. The ocicni lib will be called in
that net ns.
This design allows allows easier maintenance, no extra container
with pause processes, support for rootless cni with --uidmap
and possibly more.
The biggest problem is backwards compatibility. I don't think
live migration can be possible. If the user reboots or restart
all cni containers everything should work as expected again.
The user is left with the rootless-cni-infa container and image
but this can safely be removed.
To make the existing cni configs work we need execute the cni plugins
in a extra mount namespace. This ensures that we can safely mount over
/run and /var which have to be writeable for the cni plugins without
removing access to these files by the main podman process. One caveat
is that we need to keep the netns files at `XDG_RUNTIME_DIR/netns`
accessible.
`XDG_RUNTIME_DIR/rootless-cni/{run,var}` will be mounted to `/{run,var}`.
To ensure that we keep the netns directory we bind mount this relative
to the new root location, e.g. XDG_RUNTIME_DIR/rootless-cni/run/user/1000/netns
before we mount the run directory. The run directory is mounted recursive,
this makes the netns directory at the same path accessible as before.
This also allows iptables-legacy to work because /run/xtables.lock is
now writeable.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
Erik Sjolund reported an issue where a badly formated file
could be passed into the `--tz` option and then the date in the container
would be badly messed up:
```
erik@laptop:~$ echo Hello > file.txt
erik@laptop:~$ podman run --tz=../../../home/erik/file.txt --rm -ti
docker.io/library/alpine cat /etc/localtime
Hello
erik@laptop:~$ podman --version
podman version 3.0.0-rc1
erik@laptop:~$
```
This fix checks to make sure the TZ passed in is a valid
value and then proceeds with the rest of the processing.
This was first reported as a potential security issue, but it
was thought not to be. However, I thought closing the hole
sooner rather than later would be good.
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
The --trace has helped in early stages analyze Podman code. However,
it's contributing to dependency and binary bloat. The standard go
tooling can also help in profiling, so let's turn `--trace` into a NOP.
[NO TESTS NEEDED]
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
To be able to reuse common checkpoint/restore functions this commit
moves code to pkg/checkpoint/crutils.
This commit has not functional changes. It only moves code around.
[NO TESTS NEEDED] - only moving code around
Signed-off-by: Adrian Reber <areber@redhat.com>
We missed bumping the go module, so let's do it now :)
* Automated go code with github.com/sirkon/go-imports-rename
* Manually via `vgrep podman/v2` the rest
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Currently if the host shares container storage with a container
running podman, the podman inside of the container resets the
storage on the host. This can cause issues on the host, as
well as causes the podman command running the container, to
fail to unmount /dev/shm.
podman run -ti --rm --privileged -v /var/lib/containers:/var/lib/containers quay.io/podman/stable podman run alpine echo hello
* unlinkat /var/lib/containers/storage/overlay-containers/a7f3c9deb0656f8de1d107e7ddff2d3c3c279c11c1635f233a0bffb16051fb2c/userdata/shm: device or resource busy
* unlinkat /var/lib/containers/storage/overlay-containers/a7f3c9deb0656f8de1d107e7ddff2d3c3c279c11c1635f233a0bffb16051fb2c/userdata/shm: device or resource busy
Since podman is volume mounting in the graphroot, it will add a flag to
/run/.containerenv to tell podman inside of container whether to reset storage or not.
Since the inner podman is running inside of the container, no reason to assume this is a fresh reboot, so if "container" environment variable is set then skip
reset of storage.
Also added tests to make sure /run/.containerenv is runnig correctly.
Fixes: https://github.com/containers/podman/issues/9191
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Make sure to not set an empty $HOME for containers and let it default to
"/".
https://github.com/containers/crun/pull/599 is required to fully
address #9378.
Partially-Fixes: #9378
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Currently podman is always chowning the WORKDIR to root:root
This PR will return if the WORKDIR already exists.
Fixes: https://github.com/containers/podman/issues/9387
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The old copy-up implementation was very unhappy with symlinks,
which could cause containers to fail to start for unclear reasons
when a directory we wanted to copy-up contained one. Rewrite to
use the Buildah Copier, which is more recent and should be both
safer and less likely to blow up over links.
At the same time, fix a deadlock in copy-up for volumes requiring
mounting - the Mountpoint() function tried to take the
already-acquired volume lock.
Fixes#6003
Signed-off-by: Matthew Heon <mheon@redhat.com>
Implement podman secret create, inspect, ls, rm
Implement podman run/create --secret
Secrets are blobs of data that are sensitive.
Currently, the only secret driver supported is filedriver, which means creating a secret stores it in base64 unencrypted in a file.
After creating a secret, a user can use the --secret flag to expose the secret inside the container at /run/secrets/[secretname]
This secret will not be commited to an image on a podman commit
Signed-off-by: Ashley Cui <acui@redhat.com>
When resolving the workdir of a container, we may need to create unless
the user set it explicitly on the command line. Otherwise, we just do a
presence check. Unfortunately, there was a missing return that lead us
to fall through into attempting to create and chown the workdir. That
caused a regression when running on a read-only root fs.
Fixes: #9230
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
A container's workdir can be specified via the CLI via `--workdir` and
via an image config with the CLI having precedence.
Since images have a tendency to specify workdirs without necessarily
shipping the paths with the root FS, make sure that Podman creates the
workdir. When specified via the CLI, do not create the path, but check
for its existence and return a human-friendly error.
NOTE: `crun` is performing a similar check that would yield exit code
127. With this change, however, Podman performs the check and yields
exit code 126. Since this is specific to `crun`, I do not consider it
to be a breaking change of Podman.
Fixes: #9040
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
This implements support for mounting and unmounting volumes
backed by volume plugins. Support for actually retrieving
plugins requires a pull request to land in containers.conf and
then that to be vendored, and as such is not yet ready. Given
this, this code is only compile tested. However, the code for
everything past retrieving the plugin has been written - there is
support for creating, removing, mounting, and unmounting volumes,
which should allow full functionality once the c/common PR is
merged.
A major change is the signature of the MountPoint function for
volumes, which now, by necessity, returns an error. Named volumes
managed by a plugin do not have a mountpoint we control; instead,
it is managed entirely by the plugin. As such, we need to cache
the path in the DB, and calls to retrieve it now need to access
the DB (and may fail as such).
Notably absent is support for SELinux relabelling and chowning
these volumes. Given that we don't manage the mountpoint for
these volumes, I am extremely reluctant to try and modify it - we
could easily break the plugin trying to chown or relabel it.
Also, we had no less than *5* separate implementations of
inspecting a volume floating around in pkg/infra/abi and
pkg/api/handlers/libpod. And none of them used volume.Inspect(),
the only correct way of inspecting volumes. Remove them all and
consolidate to using the correct way. Compat API is likely still
doing things the wrong way, but that is an issue for another day.
Fixes#4304
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
`staticcheck` is a golang code analysis tool. https://staticcheck.io/
This commit fixes a lot of problems found in our code. Common problems are:
- unnecessary use of fmt.Sprintf
- duplicated imports with different names
- unnecessary check that a key exists before a delete call
There are still a lot of reported problems in the test files but I have
not looked at those.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
writing to the id map fails when an extent overlaps multiple mappings
in the parent user namespace:
$ cat /proc/self/uid_map
0 1000 1
1 100000 65536
$ unshare -U sleep 100 &
[1] 1029703
$ printf "0 0 100\n" | tee /proc/$!/uid_map
0 0 100
tee: /proc/1029703/uid_map: Operation not permitted
This limitation is particularly annoying when working with rootless
containers as each container runs in the rootless user namespace, so a
command like:
$ podman run --uidmap 0:0:2 --rm fedora echo hi
Error: writing file `/proc/664087/gid_map`: Operation not permitted: OCI permission denied
would fail since the specified mapping overlaps the first
mapping (where the user id is mapped to root) and the second extent
with the additional IDs available.
Detect such cases and automatically split the specified mapping with
the equivalent of:
$ podman run --uidmap 0:0:1 --uidmap 1:1:1 --rm fedora echo hi
hi
A fix has already been proposed for the kernel[1], but even if it
accepted it will take time until it is available in a released kernel,
so fix it also in pkg/rootless.
[1] https://lkml.kernel.org/lkml/20201203150252.1229077-1-gscrivan@redhat.com/
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
When migrating a container with associated volumes, the content of
these volumes should be made available on the destination machine.
This patch enables container checkpoint/restore with named volumes
by including the content of volumes in checkpoint file. On restore,
volumes associated with container are created and their content is
restored.
The --ignore-volumes option is introduced to disable this feature.
Example:
# podman container checkpoint --export checkpoint.tar.gz <container>
The content of all volumes associated with the container are included
in `checkpoint.tar.gz`
# podman container checkpoint --export checkpoint.tar.gz --ignore-volumes <container>
The content of volumes is not included in `checkpoint.tar.gz`. This is
useful, for example, when the checkpoint/restore is performed on the
same machine.
# podman container restore --import checkpoint.tar.gz
The associated volumes will be created and their content will be
restored. Podman will exit with an error if volumes with the same
name already exist on the system or the content of volumes is not
included in checkpoint.tar.gz
# podman container restore --ignore-volumes --import checkpoint.tar.gz
Volumes associated with container must already exist. Podman will not
create them or restore their content.
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
Instead of individual values from ContainerCheckpointOptions,
provide the options object.
This is a preparation for the next patch where one more value
of the options object is required in exportCheckpoint().
Signed-off-by: Radostin Stoyanov <rstoyanov@fedoraproject.org>
When adding the HOSTNAME environment variable, only do so if it
is not already present in the spec. If it is already present, it
was likely added by the user, and we should honor their requested
value.
Fixes#8886
Signed-off-by: Matthew Heon <mheon@redhat.com>
do not check whether the specified ID is valid in the user namespace.
crun handles this case[1], so the check in Podman prevents to get to
the OCI runtime at all.
$ podman run --user 10:0 --uidmap 0:0:1 --rm -ti fedora:33 sh -c 'id; cat /proc/self/uid_map'
uid=10(10) gid=0(root) groups=0(root),65534(nobody)
10 0 1
[1] https://github.com/containers/crun/pull/556
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This adds a new command, 'podman network reload', to reload the
networks of existing containers, forcing recreation of firewall
rules after e.g. `firewall-cmd --reload` wipes them out.
Under the hood, this works by calling CNI to tear down the
existing network, then recreate it using identical settings. We
request that CNI preserve the old IP and MAC address in most
cases (where the container only had 1 IP/MAC), but there will be
some downtime inherent to the teardown/bring-up approach. The
architecture of CNI doesn't really make doing this without
downtime easy (or maybe even possible...).
At present, this only works for root Podman, and only locally.
I don't think there is much of a point to adding remote support
(this is very much a local debugging command), but I think adding
rootless support (to kill/recreate slirp4netns) could be
valuable.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
We have been asked to leak some information into the container
to indicate:
* The name and id of the container
* The version of podman used to launch the container
* The image name and ID the container is based on.
* Whether the container engine is running in rootless mode.
Fixes: https://github.com/containers/podman/issues/6192
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Our users are missing certain warning messages that would
make debugging issues with Podman easier.
For example if you do a podman build with a Containerfile
that contains the SHELL directive, the Derective is silently
ignored.
If you run with the log-level warn you get a warning message explainging
what happened.
$ podman build --no-cache -f /tmp/Containerfile1 /tmp/
STEP 1: FROM ubi8
STEP 2: SHELL ["/bin/bash", "-c"]
STEP 3: COMMIT
--> 7a207be102a
7a207be102aa8993eceb32802e6ceb9d2603ceed9dee0fee341df63e6300882e
$ podman --log-level=warn build --no-cache -f /tmp/Containerfile1 /tmp/
STEP 1: FROM ubi8
STEP 2: SHELL ["/bin/bash", "-c"]
STEP 3: COMMIT
WARN[0000] SHELL is not supported for OCI image format, [/bin/bash -c] will be ignored. Must use `docker` format
--> 7bd96fd25b9
7bd96fd25b9f755d8a045e31187e406cf889dcf3799357ec906e90767613e95f
These messages will no longer be lost, when we default to WARNing level.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The buildah/pkg/secrts package was move to
containers/common/pkg/subscriptions.
Switch to using this by default.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
When looking up a container's cgroup path, parse /proc/[PID]/cgroup.
This will work across all cgroup managers and configurations and is
supported on cgroups v1 and v2.
Fixes: #8265
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
The --hostname and containername should always be added to containers.
Added some tests to make sure you can always ping the hostname and container
name from within the container.
Fixes: https://github.com/containers/podman/issues/8095
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Allow users to specify unbindable on volume command line
Switch internal mounts to rprivate to help prevent leaks.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Most of the builtin golang functions like os.Stat and
os.Open report errors including the file system object
path. We should not wrap these errors and put the file path
in a second time, causing stuttering of errors when they
get presented to the user.
This patch tries to cleanup a bunch of these errors.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Add a new "image" mount type to `--mount`. The source of the mount is
the name or ID of an image. The destination is the path inside the
container. Image mounts further support an optional `rw,readwrite`
parameter which if set to "true" will yield the mount writable inside
the container. Note that no changes are propagated to the image mount
on the host (which in any case is read only).
Mounts are overlay mounts. To support read-only overlay mounts, vendor
a non-release version of Buildah.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
If the resolv.conf file is empty we provide default dns servers.
If the file does not exists we error and don't create the
container. We should also provide the default entries in this
case. This is also what docker does.
Fixes#8089
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
This does not match Docker, which does not add hostname in this
case, but it seems harmless enough.
Fixes#8095
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
