Podman 1.6.2 changed systemd mode auto-detection from commands ending in
``init`` to hard-coded paths ``/sbin/init`` and ``/usr/sbin/init``. This
broke FreeIPA container. ``podman run`` and ``podman create`` now
activate systemd mode when the command is ``/usr/local/sbin/init``.
Fixes: https://github.com/containers/podman/issues/7287
Signed-off-by: Christian Heimes <cheimes@redhat.com>
To sync the behavior between AppArmor and seccomp it is now possible to
also specify seccomp profiles for privileged containers.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
Buildah and podman build can create images without a working dir.
FROM fedora
WORKDIR /test
If you build this image with caching twice, the second time the image
will not have a working dir.
Similarly if you execute
podman run --workdir /foobar fedora
It blows up since the workingdir is not created automatically.
Finally there was duplicated code for getting the workingdir
out of an image, that this PR removes.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
This matches Docker behavior, and seems to make sense - the CMD
may have been specific to the original entrypoint and probably
does not make sense if it was changed.
While we're in here, greatly simplify the logic for populating
the SpecGen's Command. We create the full command when making the
OCI spec, so the client should not be doing any more than setting
it to the Command the user passed in, and completely ignoring
ENTRYPOINT.
Fixes#7115
Signed-off-by: Matthew Heon <mheon@redhat.com>
A recent crun change stopped the creation of the container's
working directory if it does not exist. This is arguably correct
for user-specified directories, to protect against typos; it is
definitely not correct for image WORKDIR, where the image author
definitely intended for the directory to be used.
This makes Podman create the working directory and chown it to
container root, if it does not already exist, and only if it was
specified by an image, not the user.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
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>
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>
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>
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>
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>
Currently we are sending over pids-limits from the user even if they
never modified the defaults. The pids limit should be set at the server
side unless modified by the user.
This issue has led to failures on systems that were running with cgroups V1.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
In `podman inspect` output for containers and pods, we include
the command that was used to create the container. This is also
used by `podman generate systemd --new` to generate unit files.
With remote podman, the generated create commands were incorrect
since we sourced directly from os.Args on the server side, which
was guaranteed to be `podman system service` (or some variant
thereof). The solution is to pass the command along in the
Specgen or PodSpecgen, where we can source it from the client's
os.Args.
This will still be VERY iffy for mixed local/remote use (doing a
`podman --remote run ...` on a remote client then a
`podman generate systemd --new` on the server on the same
container will not work, because the `--remote` flag will slip
in) but at the very least the output of `podman inspect` will be
correct. We can look into properly handling `--remote` (parsing
it out would be a little iffy) in a future PR.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
We are using these dependencies just to get the device from path.
These dependencies no longer build on Windows, so simply cloning
the deviceFromPath function, we can eliminate the need for this
vendoring.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
If I enter a continer with --userns keep-id, my UID will be present
inside of the container, but most likely my user will not be defined.
This patch will take information about the user and stick it into the
container.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
--sdnotify container|conmon|ignore
With "conmon", we send the MAINPID, and clear the NOTIFY_SOCKET so the OCI
runtime doesn't pass it into the container. We also advertise "ready" when the
OCI runtime finishes to advertise the service as ready.
With "container", we send the MAINPID, and leave the NOTIFY_SOCKET so the OCI
runtime passes it into the container for initialization, and let the container advertise further metadata.
This is the default, which is closest to the behavior podman has done in the past.
The "ignore" option removes NOTIFY_SOCKET from the environment, so neither podman nor
any child processes will talk to systemd.
This removes the need for hardcoded CID and PID files in the command line, and
the PIDFile directive, as the pid is advertised directly through sd-notify.
Signed-off-by: Joseph Gooch <mrwizard@dok.org>
With the advent of Podman 2.0.0 we crossed the magical barrier of go
modules. While we were able to continue importing all packages inside
of the project, the project could not be vendored anymore from the
outside.
Move the go module to new major version and change all imports to
`github.com/containers/libpod/v2`. The renaming of the imports
was done via `gomove` [1].
[1] https://github.com/KSubedi/gomove
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
--tz flag sets timezone inside container
Can be set to IANA timezone as well as `local` to match host machine
Signed-off-by: Ashley Cui <acui@redhat.com>
I didn't believe that this was actually legal, but it looks like
it is. And, unlike our previous understanding (host port being
empty means just use container port), empty host port actually
carries the same meaning as `--expose` + `--publish-all` (that
is, assign a random host port to the given container port). This
requires a significant rework of our port handling code to handle
this new case. I don't foresee this being commonly used, so I
optimized having a fixed port number as fast path, which this
random assignment code running after the main port handling code
only if necessary.
Fixes#6806
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Also make sure that the limits we set for rootless are not higher than
what we'd set for root containers.
Rootless containers failed to start when the calling user already
had ulimit (e.g. on NOFILE) set.
This is basically a cherry-pick of 76f8efc0d0 into specgen
Signed-off-by: Ralf Haferkamp <rhafer@suse.com>
We have a flag, --syslog, for telling logrus to log to syslog as
well as to the terminal. Previously, this flag also set the exit
command for containers to use `--syslog` (otherwise all output
from exit commands is lost). I attempted to replicate this with
Podman v2.0, but quickly ran into circular import hell (the flag
is defined in cmd/podman, I needed it in cmd/podman/containers,
cmd/podman imports cmd/podman/containers already, etc). Instead,
let's just set the syslog flag automatically on
`--log-level=debug` so we log exit commands automatically when
debug-level logs are requested. This is consistent with Conmon
and seems to make sense.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Currently podman run --userns keep-id --user root:root fedora id
The --user flag is ignored. Removing this makes the code work correctly.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We initially believed that implementing this required support for
restarting containers after reboot, but this is not the case.
The unless-stopped restart policy acts identically to the always
restart policy except in cases related to reboot (which we do not
support yet), but it does not require that support for us to
implement it.
Changes themselves are quite simple, we need a new restart policy
constant, we need to remove existing checks that block creation
of containers when unless-stopped was used, and we need to update
the manpages.
Fixes#6508
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
These were part of Podman v1.9, but were lost in the transition
to using Specgen to create containers. Most resource limits are
checked via the sysinfo package to ensure they are safe to use
(the cgroup is mounted, kernel support is present, etc) and
removed if not safe. Further, bounds checks are performed to
ensure that values are valid.
Ensure these warnings are printed client-side when they occur.
This part is a little bit gross, as it happens in pkg/infra and
not cmd/podman, which is largely down to how we implemented
`podman run` - all the work is done in pkg/infra and it returns
only once the container has exited, and we need warnings to print
*before* the container runs. The solution here, while inelegant,
avoid the need to extensively refactor our handling of run.
Should fix blkio-limit warnings that were identified by the FCOS
test suite.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Add an `--infra-conmon-pidfile` flag to `podman-pod-create` to write the
infra container's conmon process ID to a specified path. Several
container sub-commands already support `--conmon-pidfile` which is
especially helpful to allow for systemd to access and track the conmon
processes. This allows for easily tracking the conmon process of a
pod's infra container.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Add a `CreateCommand` field to the pod config which includes the entire
`os.Args` at pod-creation. Similar to the already existing field in a
container config, we need this information to properly generate generic
systemd unit files for pods. It's a prerequisite to support the `--new`
flag for pods.
Also add the `CreateCommand` to the pod-inspect data, which can come in
handy for debugging, general inspection and certainly for the tests that
are added along with the other changes.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Systemd enablement has to happen on the server side, since we need
check if the image is running systemd.
Also need to make sure user setting the StopSignal is not overriden on the
server side. But if not set and using systemd, we set it correctly.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
