The go std os package to will always make sure to use O_CLOEXEC, however
in cases where we directly call unix.Open() we need to pass that flag
explicitly.
I looked at this as there was a report of a leaked fd on the pasta list,
though I am not sure this will address it.
But anyway doing this should be rather safe and avoid leaks into other
processes.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
ExecContainerHTTP returns attachChan to its caller before attachExecHTTP
finishes. The caller's deferred close(holdConnOpen) can therefore fire
while attachExecHTTP is still running (including its own deferred
cleanups), which races with the goroutine inside attachExecHTTP that
reads deferredErr after <-holdConnOpen unblocks.
Fix this by introducing an errCh channel: deferred functions write
deferredErr into it, and the goroutine reads from it after
<-holdConnOpen unblocks, ensuring the read happens-after all writes to
the named return value.
Fixes: #28277
Signed-off-by: crawfordxx <crawfordxx@users.noreply.github.com>
Add support for `default_host_ips` in containers.conf to set default
host IP(s) if no IP is set when forwarding ports. Multiple IPs can be
configured, and passing explicit IP with -p will always override
the configured defaults.
Signed-off-by: Danish Prakash <contact@danishpraka.sh>
rootlessport: clarify RootlessCNI comment
Update the comment for the RootlessCNI conditional to clarify that
the flag is for rootless bridge networking, not CNI specifically.
The bool is set when netStatus != nil in slirp4netns and will be
removed when slirp4netns and rootlessport are fully dropped.
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
This prevents a nil pointer crash when running network=host containers
on a FreeBSD host using podman-remote.
Fixes: #28289
Signed-off-by: Doug Rabson <dfr@rabson.org>
In the moby/moby, the namesgenerator is internal. We still want to
depend on it, so this commit copies it from moby/moby to our code-base.
The good thing is the file is frozen upstream, so no more changes are
going to appear in it.
Fixes: #27536.
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
This allows things like compose project names to be associated with log
messages and later used in log processing and analysis.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
For remote operation, start the remote service with --tls-details:
using --tls-details on the client side will only affect client's
connection.
This should eventually include many more tests - track down all current
uses of libpod.Runtime.{SystemContext,imageContext,LibimageRuntime}.
That will come later
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Currently validation that log tag requires journald driver is done in several
places and emits only warning. Making it an error and moving to
`(c *Container) validate()` is a more correct approach.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
- Don't allocate it on-demand, it will always be created in the end.
- Embed the SystemContext directly, without using a pointer,
to make it clear it always exists.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Previously, using WithRegistriesConf was setting
BigFilesTemporaryDir using buildah/internal/tmpdir, which (turns relative
$TMPDIR into absolute and) silently ignores invalid values in containers.conf
and uses /var/tmp in that case.
Without WithRegistriesConf, we would first initialize libimage with
BigFilesTemporaryDir = nil (causing libimage to determine BigFilesTemporaryDir
using a _different_ code path which fails on invalid containers.conf),
and only later set r.imageContext.BigFilesTemporaryDir.
It doesn't make sense that --registries-conf should affect TMPDIR processing
that way, and presumably the code path without --registries-conf is much
more frequently used and the one everyone expects; so drop this aspect of
WithRegistriesConf.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Require (linux || freebsd), because the code already does that, in practice.
This just means macOS users of IDEs aren't hit with thousands of compilation
errors (and then the IDE can open an Linux-specific file and then process it
under the Linux assumption, which works much better).
This commit contains the parts that differ somehow.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Require (linux || freebsd), because the code already does that, in practice.
This just means macOS users of IDEs aren't hit with thousands of compilation
errors (and then the IDE can open an Linux-specific file and then process it
under the Linux assumption, which works much better).
This commit ONLY replaces
//go:build !remote
with
//go:build !remote && (linux || freebsd)
and is split from the rest to allow mechanically verifying that fact,
and focusing a review on the other kinds of changes.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Add a per-volume 'nocreate' option that prevents automatic creation of
named volumes when they don't exist. When specified, Podman will fail
if the volume is not found instead of creating it automatically.
Usage: -v myvolume:/data:nocreate
--mount type=volume,src=myvolume,dst=/data,nocreate
See: #27862
Signed-off-by: Ygal Blum <ygal.blum@gmail.com>
The orginal motivation was to give a hint to users to delete the file if
they did not create the storage.conf file since some early versions of
podman did auto generate that file[1].
However that was a really long time ago and with the config file rework
there can be many different storage.conf paths so this warning is no
longer useful so we should be able to remove this now.
[1] https://github.com/containers/podman/issues/7447
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Given the new config file logic will read many files pritning one
specific one here has no meaning anymore, just delete it.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
As I outlined in the design docs this is broken, there are several
data races here because we write to the config files that can be read by
other goroutines in parallel which violates the go memory model and
thus can lead to runtime panics and undefined behavior.
One could fix with a mutex but that would make the whole code base much
more ugly and there is still the risk that something would access this
field without the mutex held.
I am not sure we have any users using this, it never worked for the
storage side and since the service is a not a daemon any user could just
stop and start it again to re-read the files without having to stop
running containers.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In the currently used go.podman.io/common/pkg/libartifact version
there is no store subpackage (yet). Fix the import statement and
usage accordingly.
Fixes: df0e3b6ec7 ("libpod: move artifact volume validation to creation phase"
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Apparently, prealloc got much smarter in this version, so let's disable
it for _test.go files as we're not really interested in
micro-optimizations for the test code.
The rest of its warnings is being fixed by the earlier commits.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Do not reuse names slice for the unrelated data. This fixes the
following prealoc warning:
> libpod/storage.go:109:2: Consider preallocating names with capacity 2 (prealloc)
> names := []string{containerName}
> ^
This commit is part of series fixing issues reported by prealloc linter
from golangci-lint v2.8.0.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Instead of creating a slice and then appending to it, let's inline the
initial slice into append. This may or may not result in less slice
reallocations, but it is silencing the prealloc linter warnings.
This commit is part of series fixing issues reported by prealloc linter
from golangci-lint v2.8.0.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
When we already know the resulting slice size but still need/want to use
append, it makes sense to preallocate the slice by using make with the
capacity argument.
This commit is part of series fixing issues reported by prealloc linter
from golangci-lint v2.8.0.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
