| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
Addresses the multiple "default" userns values found
in the podman-run(1) man page: http://docs.podman.io/en/latest/markdown/podman-run.1.html.
This in response to: https://bugzilla.redhat.com/show_bug.cgi?id=1860126
which this PR wil fix.
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
|
| |
|
|
|
|
| |
do not pass network specific options through the network namespace.
Signed-off-by: Giuseppe Scrivano <gscrivan@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>
|
| |
|
|
|
|
|
| |
if some mappings are specified, assume there is a private user
namespace.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
| |
|
|
|
|
|
| |
automatically pick an empty range and create an user namespace for the
container.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
| |
|
|
|
|
|
| |
vendor in c/common config pkg for containers.conf
Signed-off-by: Qi Wang qiwan@redhat.com
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
change the default on cgroups v2 and create a new cgroup namespace.
When a cgroup namespace is used, processes inside the namespace are
only able to see cgroup paths relative to the cgroup namespace root
and not have full visibility on all the cgroups present on the
system.
The previous behaviour is maintained on a cgroups v1 host, where a
cgroup namespace is not created by default.
Closes: https://github.com/containers/libpod/issues/4363
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
| |
|
|
|
|
|
| |
If we call Container(), we expect the namespace to be prefixed with "container:".
Add this check, and refactor to use named const strings instead of string literals
Signed-off-by: Peter Hunt <pehunt@redhat.com>
|
| |
|
|
|
|
|
|
| |
allow to join the user namespace of another container.
Closes: https://github.com/containers/libpod/issues/3629
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
allow a container to run in a new cgroup namespace.
When running in a new cgroup namespace, the current cgroup appears to
be the root, so that there is no way for the container to access
cgroups outside of its own subtree.
By default it uses --cgroup=host to keep the previous behavior.
To create a new namespace, --cgroup=private must be provided.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
| |
|
|
|
|
|
| |
it creates a namespace where the current UID:GID on the host is mapped
to the same UID:GID in the container.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
| |
|
|
| |
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We accidentally patched this out trying to enable ns:/path/to/ns
This should restore the ability to configure nondefault CNI
networks with Podman, by ensuring that they request creation of a
network namespace.
Completely remove the WithNetNS() call when we do use an explicit
namespace from a path. We use that call to indicate that a netns
is going to be created - there should not be any question about
whether it actually does.
Fixes #2795
Signed-off-by: Matthew Heon <mheon@redhat.com>
|
| |
|
|
| |
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
|
| |
|
|
|
|
|
|
| |
so that inspect reports the correct network configuration.
Closes: https://github.com/containers/libpod/issues/1453
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
| |
|
|
|
|
|
| |
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #1507
Approved by: rhatdan
|
|
|
We should be sharing cgroups namespace by default in pods
uts namespace sharing was broken in pods.
Create a new libpod/pkg/namespaces for handling of namespace fields
in containers
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Closes: #1418
Approved by: mheon
|
