The --env is used to add new environment variable to container or
override the existing one. The --unsetenv is used to remove
the environment variable.
It is done by sharing "env" and "unsetenv" flags between both
"update" and "create" commands and later handling these flags
in the "update" command handler.
The list of environment variables to add/remove is stored
in newly added variables in the ContainerUpdateOptions.
The Container.Update API call is refactored to take
the ContainerUpdateOptions as an input to limit the number of its
arguments.
The Env and UnsetEnv lists are later handled using the envLib
package and the Container is updated.
The remote API is also extended to handle Env and EnvUnset.
Fixes: #24875
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
when the code was first added, there was no securejoin.OpenInRoot().
Since there is a function already provided by a dependency and already
used in libpod, replace the custom code with securejoin.OpenInRoot().
The new version does not report a symlink that points outside the
root, but it is still resolved relative to the specified mountpoint,
since that is the openat2 semantic. It does not affect the security
of the function.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Have one function without a `defer lock.unlock()` as one of the
commands in it calls a function that also takes the same lock,
so the unlock has to happen prior to function completion.
Unfortunately, this is prone to errors, like the one here: I
missed a case, and we could return without unlocking, causing a
deadlock later in the cleanup code as we tried to take the same
lock again.
Refactor the command to use `defer unlock()` to simplify and
avoid any further errors of this type.
Introduced by e66b788a51 - this
should be included in any backports of that commit.
Fixes#25585
Signed-off-by: Matt Heon <mheon@redhat.com>
do not run the expensive pmount.GetMounts() function if it is not
needed.
As a follow-up for commit c9c44d400c, do
not restore the propagation flag for the parent mount to shared unless
it was changed to slave first.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
AS pointed out by Valentin on #25491, it is not an actual bug but this
is makes it more clear how it works and should not confuse readers why
this case has no return.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
GoLang sets unset values to the default value of the type. This means that the destination of the log is an empty string and the count and size are set to 0. However, this means that size and count are unbounded, and this is not the default behavior.
Fixes: https://github.com/containers/podman/issues/25473
Fixes: https://issues.redhat.com/browse/RHEL-83262
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
Add a new option to allow for mounting artifacts in the container, the
syntax is added to the existing --mount option:
type=artifact,src=$artifactName,dest=/path[,digest=x][,title=x]
This works very similar to image mounts. The name is passed down into
the container config and then on each start we lookup the artifact and
the figure out which blobs to mount. There is no protaction against a
user removing the artifact while still being used in a container. When
the container is running the bind mounted files will stay there (as the
kernel keeps the mounts active even if the bind source was deleted).
On the next start it will fail to start as if it does not find the
artifact. The good thing is that this technically allows someone to
update the artifact with the new file by creating a new artifact with
the same name.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Instead of duplicating the NewArtifactStore() call in many places and
having to make sure we always pass the same path to it define it as
function on the runtime. This allows any caller with access to the
libpod runtime to create the store easily.
This is suing a sync.OnceValues() function so the store is initialized
only once and only when actually needed.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
There are multiple concurrent goroutinces which produce result and they
race agains each other, while producing different results.
This commit addresses at least a part of the problem - producing
different results for competing "sources".
Fixes: #25479
Signed-off-by: Yuri Timenkov <yuri@timenkov.pro>
When waiting for container to be not-running, sometimes wait retuns code
-1 with an empty error instead of actual exit code.
It turned out that syncContainer returns ErrCtrRemoved for a removed
container instead of ErrNoSuchCtr, while data can still be pulled from
the database.
This fixes the issue by taking into account both codes.
Fixes: #25479
Signed-off-by: Yuri Timenkov <yuri@timenkov.pro>
When starting a container consider healthcheck errors fatal. That way
user know when systemd-run failed to setup the timer to run the
healthcheck and we don't get into a state where the container is running
but not the healthcheck.
This also fixes the broken error reporting from the systemd-run exec, if
the binary could not be run the output was just empty leaving the users
with no idea what failed.
Fixes#25034
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This commit adds the "secret" Event type and emits
"create" and "remove" events for this Event type
when Secret is created or removed.
This can be used for example by podman interfaces to
view and manage secrets.
Fixes: #24030
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
This resolves an ordering issue that prevented quotas from being
applied. XFS quotas are applied recursively, but only for
subdirectories created after the quota is applied; if we create
`_data` before the quota, and then use `_data` for all data in
the volume, the quota will never be used by the volume.
Also, add a test that volume quotas are working as designed using
an XFS formatted loop device in the system tests. This should
prevent any further regressions on basic quota functionality,
such as quotas being shared between volumes.
Fixes#25368
Signed-off-by: Matt Heon <mheon@redhat.com>
This greatly simplifies the locking around these two functions,
and things end up looking a lot more elegant. This should prevent
the race flakes we were seeing before.
Fixes#25289
Signed-off-by: Matt Heon <mheon@redhat.com>
This seems to have been added as part of the cleanup of our
handling of OOM files, but code was never added to remove it, so
we leaked a single directory with an exit file and OOM file per
container run. Apparently have been doing this for a while - I'd
guess since March of '23 - so I'm surprised more people didn't
notice.
Fixes#25291
Signed-off-by: Matt Heon <mheon@redhat.com>
This was discovered by a user while testing Podman on FreeBSD
(oci-playground/freebsd-podman-testing/issues/17). The error message
didn't stop 'podman system reset' from working and this commit simply
suppressses the error on FreeBSD.
Signed-off-by: Doug Rabson <dfr@rabson.org>
As part of our database init, we perform a check of the current
values for a few fields (graph driver, graph root, static dir,
and a few more) to validate that Libpod is being started with a
sane & sensible config, and the user's containers can actually be
expected to work. Basically, we take the current runtime config
and compare against values cached in the database from the first
time Podman was run.
We've had some issues with this logic before this year around
symlink resolution, but this is a new edge case. Somehow, the
database is being loaded with the empty string for some fields
(at least graph driver) which is causing comparisons to fail
because we will never compare against "" for those fields - we
insert the default value instead, assuming we have one.
Having a value of "" in the database largely invalidates the
check so arguably we could just drop it, but what BoltDB did -
and what SQLite does after this patch - is to use the default
value for comparison instead of "". This should still catch some
edge cases, and shouldn't be too harmful.
What this does not do is identify or solve the reason that we are
seeing the empty string in the database at all. From my read on
the logic, it must mean that the graph driver is explicitly set
to "" in the c/storage config at the time Podman is first run and
I'm not precisely sure how that happens.
Fixes#24738
Signed-off-by: Matt Heon <mheon@redhat.com>
I'm not sure if there is an equivalent to CAP_SYS_RESOURCE on FreeBSD
but for now, I have added a no-op stub which returns false.
Signed-off-by: Doug Rabson <dfr@rabson.org>
First, refactor our existing graph traversal code to improve code
sharing. There still isn't much sharing between inward traversal
(stop, remove) and outward traversal (start) but stop and remove
are sharing most of their code, which seems a positive.
Second, add a new graph-traversal function to stop containers.
We already had start and remove; stop uses the newly-refactored
inward-traversal code which it shares with removal.
Third, rework the shared stop/removal inward-traversal code to
add locking. This allows parallel execution of stop and removal,
which should improve the performance of `podman pod rm` and
retain the performance of `podman pod stop` at about what it is
right now.
Fourth and finally, use the new graph-based stop when possible
to solve unordered stop problems with pods - specifically, the
infra container stopping before application containers, leaving
those containers without a working network.
Fixes https://issues.redhat.com/browse/RHEL-76827
Signed-off-by: Matt Heon <mheon@redhat.com>
The intention behind this is to stop races between
`pod stop|start` and `container stop|start` being run at the same
time. This could result in containers with no working network
(they join the still-running infra container's netns, which is
then torn down as the infra container is stopped, leaving the
container in an otherwise unused, nonfunctional, orphan netns.
Locking the pod (if present) in the public container start and
stop APIs should be sufficient to stop this.
Signed-off-by: Matt Heon <mheon@redhat.com>
podman exec support detaching early via the detach key sequence. In that
case the podman process should exit successfully but the container exec
process keeps running.
Now I wrote automated test for both podman run and exec detach but this
uncovered several larger issues:
- detach sequence parsing is broken[1]
- podman-remote exec detach is broken[2]
- detach in general seems to be buggy/racy, seeing lot of flakes that
fail to restore the terminal and get an EIO instead, i.e.
"Unable to restore terminal: input/output error"
Thus I cannot add tests for now but this commit should at least fix the
obvoius case as reported by the user so I like to get this in regardless
and I will work through the other issues once I have more time.
Fixes#24895
[1] https://github.com/containers/common/pull/2302
[2] https://github.com/containers/podman/issues/25089
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
BuildOrigin is a field that can be set at build time by packagers. This helps us trace how and where the binary was built and installed from, allowing us to see if the issue is due to a specfic installation or a general podman bug. This field shows up in podman version and in podman info when populated. Note that podman info has a new field, Client, that only appears when running podman info using the remote client.
Automatically set the BuildOrigin field when building the macOS pkginstaller to pkginstaller.
Usage: make podman-remote BUILD_ORIGIN="mypackaging"
Signed-off-by: Ashley Cui <acui@redhat.com>
The `podman system prune` command is able to remove build containers that were created during the build, but were not removed because the build terminated unexpectedly.
By default, build containers are not removed to prevent interference with builds in progress. Use the **--build** flag when running the command to remove build containers as well.
Fixes: https://issues.redhat.com/browse/RHEL-62009
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
This did not have a JSON tag prior to being added by #25008. By
adding one we risk a breaking change in the DB (particularly
given the change in case - useImageHosts vs UseImageHosts) which
we should try to avoid.
Remove the tag given this.
Signed-off-by: Matt Heon <mheon@redhat.com>
Fixes: https://github.com/containers/podman/issues/25002
Also add the ability to inspect containers for
UseImageHosts and UseImageHostname.
Finally fixed some bugs in handling of --no-hosts for Pods,
which I descovered.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Fix new issues found by usetesting, mainly we should use t.TempDir() in
test which makes the code better as this will be removed on test end
automatically so no need for defer or any error checking.
Also fix issues reported by exptostd, these mainly show where we can
switch the imports to the std maps/slices packages instead of the
golang.org/x/exp/... packages.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Passing the hostname allows netavark to include it in DHCP lease
requests which, in an environment where DDNS is used, can cause
DNS entries to be created automatically.
* The current Hostname() function in container.go was updated to
check the new `container_name_as_hostname` option in the
CONTAINERS table of containers.conf. If set and no hostname
was configured for the container, it causes the hostname to be
set to a version of the container's name with the characters not
valid for a hostname removed. If not set (the default), the original
behavior of setting the hostname to the short container ID is
preserved.
* Because the Hostname() function can return the host's hostname
if the container isn't running in a private UTS namespace, and we'd
NEVER want to send _that_ in a DHCP request for a container, a new
function NetworkHostname() was added which functions like Hostname()
except that it will return an empty string instead of the host's
hostname if the container is not running in a private UTS namespace.
* networking_common.getNetworkOptions() now uses NetworkHostname()
to set the ContainerHostname member of the NetworkOptions structure.
That member was added to the structure in a corresponding commit in
common/libnetwork/types/network.go.
* Added test to containers_conf_test.go
Signed-off-by: George Joseph <g.devel@wxy78.net>
with defaults values when changes configuration with podman update.
The new LinuxResource structure does not represent the current unchanged configuration, which was not affected by the change.
Fixes: https://issues.redhat.com/browse/RUN-2375
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
The command `podman info` returned only one imagestore in
`store.graphOptions.<driver>.imagestore` even if multiple
image stores were configured.
This change replaces the field `<driver>.imagestore` with
the field `<driver>.additionalImageStores`, that instead
of a string is an array of strings and that includes all
the configured additional image stores.
Fix https://github.com/containers/storage/issues/2094
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Move error checking of possible null returned value before
its dereference in importBuilder.Format
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Tigran Sogomonian <tsogomonian@astralinux.ru>
commit 5ebba75dbd implemented this
behaviour for rootless users and later commit
0a69aefa41 changed it when in a user
namespace, but the same limitation exists for root without
CAP_SYS_RESOURCE. Change the check to use the clamp to the current
values if running without CAP_SYS_RESOURCE.
Closes: https://github.com/containers/podman/issues/24692
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This solves several problems with copying into volumes on a
container that is not running.
The first, and most obvious, is that we were previously entirely
unable to copy into a volume that required mounting - like
image volumes, volume plugins, and volumes that specified mount
options.
The second is that this fixed several permissions and content
issues with a fresh volume and a container that has not been run
before. A copy-up will not have occurred, so permissions on the
volume root will not have been set and content will not have been
copied into the volume.
If the container is running, this is very low cost - we maintain
a mount counter for named volumes, so it's just an increment in
the DB if the volume actually needs mounting, and a no-op if it
doesn't.
Unfortunately, we also have to fix permissions, and that is
rather more complicated. This involves an ugly set of manual
edits to the volume state to ensure that the permissions fixes
actually worked, as the code was never meant to be used in this
way. It's really ugly, but necessary to reach full Docker
compatibility.
Fixes#24405
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
This reverts commit 5de7b7c3f3.
We now require the Unregister shutdown handler function for
handling unmounting named volumes after `podman cp` into a
stopped container.
Signed-off-by: Matt Heon <mheon@redhat.com>
1. Completed the EventerType comment.
2. Changed EventerType to be represented as a string.
3. Since EventerType is designed to be entirely lowercase, changed the comparison to use lowercase instead of uppercase.
4. Renamed newEventJournalD to newJournalDEventer.
5. Removed redundant error-checking steps in events_linux.go.
Signed-off-by: ksw2000 <13825170+ksw2000@users.noreply.github.com>
* Add --hosts-file flag to container create, container run and pod create
* Add HostsFile field to pod inspect and container inspect results
* Test BaseHostsFile config in containers.conf
Signed-off-by: Gavin Lam <gavin.oss@tutamail.com>
New flags in a `podman update` can change the configuration of HealthCheck when the container is started, without having to restart or recreate the container.
This can help determine why a given container suddenly started failing HealthCheck without interfering with the services it provides. For example, reconfigure HealthCheck to keep logs longer than the usual last X results, store logs to other destinations, etc.
Fixes: https://issues.redhat.com/browse/RHEL-60561
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
In theory RootlessNetnsInfo() should never return nil here. However that
was actually only true when the rootless netns was set up before and
wrote the right cache file with the ip addresses.
Given this cache file is a new feature just added in 5.3 if you updated
from 5.2 or earlier the file will not exists thus cause failures for all
following started containers.
The fix for this is to stop all containers and make sure the
rootless-netns was removed so the next start creates it new with the
proper 5.3 cache file. However as there is no way to rely on users doing
that and it is also not requirement so simply handle the nil deref here.
The only way to test this would be to run the old version then the new
version which we cannot really do in CI. We do have upgrade test for
that but they are root only and likely need a lot more work to get them
going rootless but certainly worth to explore to prevent such problems
in the future.
Fixes: a1e6603133 ("libpod: make use of new pasta option from c/common")
Fixes: #24566
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
commit 5ebba75dbd implemented this
behaviour for rootless users, but the same limitation exists for any
user in a user namespace. Change the check to use the clamp to the
current values anytime podman runs in a user namespace.
Closes: https://github.com/containers/podman/issues/24508
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
All the backend work was done a while back for image volumes, so
this is effectively just plumbing the option in for volumes in
the parser logic. We do need to change the return type of the
volume parser as it only worked on spec.Mount before (which does
not have subpath support, so we'd have to pass it as an option
and parse it again) but that is cleaner than the alternative.
Fixes#20661
Signed-off-by: Matt Heon <mheon@redhat.com>
Add support for inspecting Mounts which include SubPaths.
Handle SubPaths for kubernetes image volumes.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
This commit resolves an issue where network creation and removal events were not being logged in `podman events`. A new function has been introduced in the `events` package to ensure consistent logging of network lifecycle events. This update will allow users to track network operations more effectively through the event log, improving visibility and aiding in debugging network-related issues.
Fixes: #24032
Signed-off-by: Sainath Sativar <Sativar.sainath@gmail.com>
This is not needed and was added by during debugging but it turned out
to be something else. We should not lock the thread unless needed
because this just raises question why it is here otherwise.
Also the lock would not do much as we spawn a goroutine below anyway so
it runs on another thread no matter what.
From the review comment by Miloslav but it was merged before I had the
chance to fix it:
https://github.com/containers/podman/pull/24406#discussion_r1828102666
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
One of the problems with the Events() API was that you had to call it in
a new goroutine. This meant the the error returned by it had to be read
back via a second channel. This cuased other bugs in the past but here
the biggest problem is that basic errors such as invalid since/until
options were not directly returned to the caller.
It meant in the API we were not able to write http code 200 quickly
because we always waited for the first event or error from the
channels. This in turn made some clients not happy as they assume the
server hangs on time out if no such events are generated.
To fix this we resturcture the entire event flow. First we spawn the
goroutine inside the eventer Read() function so not all the callers have
to. Then we can return the basic error quickly without the goroutine.
The caller then checks the error like any normal function and the API
can use this one to decide which status code to return.
Second we now return errors/event in one channel then the callers can
decide to ignore or log them which makes it a bit more clear.
Fixes c46884aa93 ("podman events: check for an error after we finish reading events")
Fixes#23712
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This type is unsused, undocumented and basically broken. If this would
be used anywhere it will just deadlock after writing 100+ events without
reading as the channel will just be full.
It was added in commit 8da5f3f733 but never used there nor is there any
justification why this was added in the commit message or PR comments.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Using the internal Wait() API over the events API as this is much more
efficient. Reading events will need to read a lot of data otherwise.
For the function here it should work fine and it is even better as it
does not depend on the event logger at all.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Setup2() calls Setup() so they are both the same thing, the idea was to
keep Setup2() around in c/common for a bit to avoid breaking changes
during our regular vendoring. Now just use Setup() so we can get rid of
Setup2() in c/common.
a7415c3eab
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The cgroup.Stat() operation is not atomic, so it's possible that the
cgroup is removed during the Stat() call. Catch specific errors that
can occur when the cgroup is missing and validate the existence of the
cgroup path.
If the cgroup is not found, return a more specific error indicating
that the container has been removed.
Closes: https://github.com/containers/podman/issues/23789
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
We reset the failed unit to not leak it, however we did so before
stopping, this is wrong because when the stop fails we will again have a
failed unit. The correct thing is to reset after the stop because once
it is stopped it cannot create new errors.
I found this using the following reproducer and this is enough to fix
it:
```
while :; do
cid=$(podman run -d --name foo --health-cmd /home/podman/healthcheck \
--health-startup-cmd /home/podman/healthcheck \
quay.io/libpod/testimage:20241011 /home/podman/pause)
podman healthcheck run $cid
podman rm -fa
sleep 2
systemctl --user list-units --failed | grep $cid && break
done
```
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The startup service is special because we have to transition from
startup to the normal unit. And in order to do so we kill ourselves (as
we are run as part of the service). This means we always exited 1 which
causes systemd to keep us failure and not remove the transient unit
unless "reset-failed" is called. As there is no process around to do
that we cannot really do this, thus make us exit(0) which makes more
sense.
Of course we could try to reset-failed the unit later but the code for
that seems more complicated than that.
Add a new test from Ed that ensures we check for all healthcheck units
not just the timer to avoid leaks. I slightly modified it to provide a
better error on leaks.
Fixes: 0bbef4b830 ("libpod: rework shutdown handler flow")
Fixes: #24351
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This will appease the higher-level quota logic. Basically, to
find a free quota ID to prevent reuse, we will iterate through
the contents of the directory and check the quota IDs of all
subdirectories, then use the first free ID found that is larger
than the base ID (the one set on the base directory). Problem:
our volumes use a two-tier directory structure, where the volume
has an outer directory (with the name of the actual volume) and
an inner directory (always named _data). We were only setting the
quota on _data, meaning the outer directory did not have an ID,
and the ID-choosing logic thus never detected that any IDs had
been allocated and always chose the same ID.
Setting the ID on the outer directory with PROJINHERIT set makes
the ID allocation logic work properly, and guarantees children
inherit the ID - so _data and all contents of the volume get the
ID as we'd expect.
No tests as we don't have a filesystem in our CI that supports
XFS quotas (setting it on / needs kernel flags added).
Fixes https://issues.redhat.com/browse/RHEL-18038
Signed-off-by: Matt Heon <mheon@redhat.com>
the previous implementation was expecting the rlimits to be set for the
entire process and clamping the values only when running as rootless.
Change the implementation to always specify the expected values in the
OCI spec file and do the clamping only when running as rootless and
using the default values.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
In the common scenario of podman-remote run --rm the API is required to
attach + start + wait to get exit code. This has the problem that the
wait call races against the container removal from the cleanup process
so it may not get the exit code back. However we keep the exit code
around for longer than the container so we can just look it up in the
endpoint. Of course this only works when we get a full id as param but
podman-remote will do that.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>