4 ms·

You can do all these but the disk quota with systemd. If you don't want to define a unit file, you can use the CLI: sudo systemd-nspawn \ --directo

You can do all these but the disk quota with systemd. If you don't want to define a unit file, you can use the CLI: sudo systemd-nspawn \ --directory=/ \ --volatile=yes \ --bind=/home/tmp:/home/tmp \ --private-network \ --port=tcp:80:8000 \ --property=CPUQuota=5% \ --property=MemoryMax=1G \ -- \ bash -c 'yes > /dev/null'

boring_twenties 3y ago
From systemd-nspawn man page: Like all other systemd-nspawn features, this is not a security feature and provides protection against accidental destructive operations only.
- progval 3y ago
  Isn't it a general warning about the kernel's isolation features?
apitman 3y ago
Yes but sudo. You shouldn't have to escalate privileges to decrease privileges. Docker has the same problem. This has improved somewhat with user namespaces but it's still comicated and requires root to set up.
- totallywrong 3y ago
  You can do it very easily with podman without sudo or any root access.
  - anderspitman 3y ago
    The aforementioned user namespaces and accompanying complexity come into play here, and you're going to take a performance hit using FUSE for fs and slirp for networking. I'm not saying these are bad tools, just that we need something simpler without sacrificing performance.
    - totallywrong 3y ago
      There might be complexity under the hood, but on a fresh Fedora install I can do, out of the box: $ podman run -it myimage bash Fuse is rather irrelevant since I will mount volumes if I need to do IO. And slirp has been benchmarked to 9+ Gbps. So sure there's always room for improvement but the current situation is pretty sweet imo.
- progval 3y ago
  Yes, I don't understand why systemd doesn't support it sudo-less. It's even designed to run units configured by unprivileged users, but those can't access sandboxing features at all.
itsTyrion 3y ago
What does the last line do? O_o

boring_twenties 3y ago

From systemd-nspawn man page: Like all other systemd-nspawn features, this is not a security feature and provides protection against accidental destructive operations only.

progval 3y ago
Isn't it a general warning about the kernel's isolation features?

apitman 3y ago

Yes but sudo. You shouldn't have to escalate privileges to decrease privileges. Docker has the same problem. This has improved somewhat with user namespaces but it's still comicated and requires root to set up.

totallywrong 3y ago
You can do it very easily with podman without sudo or any root access.
- anderspitman 3y ago
  The aforementioned user namespaces and accompanying complexity come into play here, and you're going to take a performance hit using FUSE for fs and slirp for networking. I'm not saying these are bad tools, just that we need something simpler without sacrificing performance.
  - totallywrong 3y ago
    There might be complexity under the hood, but on a fresh Fedora install I can do, out of the box: $ podman run -it myimage bash Fuse is rather irrelevant since I will mount volumes if I need to do IO. And slirp has been benchmarked to 9+ Gbps. So sure there's always room for improvement but the current situation is pretty sweet imo.
progval 3y ago
Yes, I don't understand why systemd doesn't support it sudo-less. It's even designed to run units configured by unprivileged users, but those can't access sandboxing features at all.

itsTyrion 3y ago

What does the last line do? O_o