mirror of
https://github.com/containers/podman.git
synced 2025-06-03 20:33:20 +08:00
362eca6691
As requested in containers/podman/issues/20000, add a `privileged` field to the containers table in containers.conf. I was hesitant to add such a field at first (for security reasons) but I understand that such a field can come in handy when using modules - certain workloads require a privileged container. Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
24 lines
1.1 KiB
Markdown
24 lines
1.1 KiB
Markdown
####> This option file is used in:
|
|
####> podman create, exec, run
|
|
####> If file is edited, make sure the changes
|
|
####> are applicable to all of those.
|
|
#### **--privileged**
|
|
|
|
Give extended privileges to this container. The default is **false**.
|
|
|
|
By default, Podman containers are unprivileged (**=false**) and cannot, for
|
|
example, modify parts of the operating system. This is because by default a
|
|
container is only allowed limited access to devices. A "privileged" container
|
|
is given the same access to devices as the user launching the container, with
|
|
the exception of virtual consoles (_/dev/tty\d+_) when running in systemd
|
|
mode (**--systemd=always**).
|
|
|
|
A privileged container turns off the security features that isolate the
|
|
container from the host. Dropped Capabilities, limited devices, read-only mount
|
|
points, Apparmor/SELinux separation, and Seccomp filters are all disabled.
|
|
Due to the disabled security features, the privileged field should almost never
|
|
be set as containers can easily break out of confinement.
|
|
|
|
Containers running in a user namespace (e.g., rootless containers) cannot have
|
|
more privileges than the user that launched them.
|