Podman Desktop 1.0 Released As An Alternative To Docker Desktop

[phoronix]

Phoronix: Podman Desktop 1.0 Released As An Alternative To Docker Desktop

Released this week from the Red Hat Summit is Podman Desktop 1.0 as a container management tool akin to Docker Desktop...

https://www.phoronix.com/news/Podman-Desktop-1.0

[kloczek]

The last thing which Linux needs ti desktop container management tool.

In case of Linux there are tons of missing things on kernel layer. Few most important:
- container has no isolated procfs
-- anyone who is logged in container can see bare metal system details
-- reboot of the container has no impact on uptime of the container (it shares uptime with bare metal system)
-- core dumps are not isolated and cannot be catch in container and at the same time container can "spam" bare meta storage
- devfs is not isolated and it is not possible to define block access to exact block devices in container

[Ironmask]

The last thing which Linux needs ti desktop container management tool.

In case of Linux there are tons of missing things on kernel layer. Few most important:
- container has no isolated procfs
-- anyone who is logged in container can see bare metal system details
-- reboot of the container has no impact on uptime of the container (it shares uptime with bare metal system)
-- core dumps are not isolated and cannot be catch in container and at the same time container can "spam" bare meta storage
- devfs is not isolated and it is not possible to define block access to exact block devices in container

I think containers are mostly just for ease of deployment.
Ideally you shouldn't need too much security, as the software you're using in itself should be secure. If you can't even trust it in a VM, why use it at all?
(This is why nobody should ever use anything written in Java, but they do anyway. VMs should not be a stop-gap for the world's most insecure language.)

[kloczek]

I think containers are mostly just for ease of deployment.
Ideally you shouldn't need too much security, as the software you're using in itself should be secure. If you can't even trust it in a VM, why use it at all?
(This is why nobody should ever use anything written in Java, but they do anyway. VMs should not be a stop-gap for the world's most insecure language.)

All those things + things like FULL network stack virtualisation (no network bridges needed on bringing up network layer) was present from FIRST DAY of availability of Solaris zones +14 years ago.
Effect of not finishing namespaces on Linux is that we have now +10 implementations of namespaces management and none are able to fully work.

Result of lack of privileges management on Linux is that namespace UIDS must be mapped to bare metal/global zone system UIDS.
In case of Solaris you can easily specify stripping down privs of zone and even if someone will run something with UID=0 will be not bale to do out of those privs.

https://docs.huihoo.com/opensolaris/solaris-containers-resource-management-and-solaris-zones/html/p91.html

On Linux you can cap memory and CPU usage however you cannot cap per zone memory used to cache VFS layer.
Result is that if you have namespace which will be reading like crazy its own VFS data and size of those data will exceed physical memory it can kick off other namespaces cached data causing performance issues.
More .. using in namespace "echo 3 >/proc/sys/vm/drop_caches" you can flush cached data used by namespaces.

All that is only tip of the iceberg and fact that namespaces are after more than decade are still not finished causes that no one ne is uses them in some serious use cases.

[anarki2]

They need to finally implement WSL integration. Until then, it's utterly useless for me. All my container workflow is in WSL.

[archkde]

- container has no isolated procfs
-- anyone who is logged in container can see bare metal system details
-- reboot of the container has no impact on uptime of the container (it shares uptime with bare metal system)
-- core dumps are not isolated and cannot be catch in container and at the same time container can "spam" bare meta storage

You should not bind the host /proc, but instead mount your own procfs inside the container. This only leaves a bit of the second and the third point, which do not sound too bad.

- devfs is not isolated and it is not possible to define block access to exact block devices in container

I'm not sure what you really mean here, but defining device access inside the container is in fact pretty annoying. Easiest way is to bind the allowed device files from the host, with obvious limitations.

[Nuc!eoN]

IMHO they should first attempt to make podman-compose feature equivalent to docker-compose. So far podman tooling is a joke.

[Anarchy]

podman "desktop" for when your podman is incomplete, buggy and missing features. gg redhat.

[panikal]

Just curious what all the hate about podman is about. My use cases are relatively light but have included a few compose tasks and seemed to work fine. I haven't had to do lots of local bridge networking/sidecar proxying etc with podman, but I did implement a couple of freeipa containers using selinux rulesets using podman for a small cloud vpn/auth stack so I'm really curious what is lacking.

[kloczek]

You should not bind the host /proc, but instead mount your own procfs inside the container. This only leaves a bit of the second and the third point, which do not sound too bad.

Please test mounting procfs inside for example lxc zone.

I'm not sure what you really mean here, but defining device access inside the container is in fact pretty annoying. Easiest way is to bind the allowed device files from the host, with obvious limitations.

If you have no devfs isolation it is possible for example mount bare metal system, root fs inside zone and change whatever you want.
In case of zfs it is concept called "zoned" which allow as well mask parent fs in zfs pool to hide from where zone fs has been mounted.
You can as well limit for the zone access to only exact storage devices

https://docs.oracle.com/cd/E37838_01/html/E61040/grzyv.html#VLZCRuris

In case of Linux namespaces there is no ANY kernel API which allows to limit access to exact storage devices.
In any Linux namespace you have FULL access to everything you want.