On 3/17/20 2:40 PM, Thomas Lamprecht wrote:
On 3/17/20 2:33 PM, Wolfgang Bumiller wrote:
On 3/17/20 2:24 PM, Thomas Lamprecht wrote:
On 3/17/20 2:10 PM, Wolfgang Bumiller wrote:
On 3/17/20 12:31 PM, Thomas Lamprecht wrote:
On 3/17/20 10:27 AM, Wolfgang Bumiller wrote:
On 3/17/20 7:35 AM, Thomas Lamprecht wrote:
CONTAINER_INTERFACE[0] is omething systemd people call their API and
we need to adapt to it a bit, even if it means doing stupid
unnecessary things, as else systemd decides to regress and suddenly
break network stack in CT after an upgrade[1].
This mounts the parent /sys as ro, child mounts can be whatever.
Fixes the system regression introduced by[2].
[0]: https://systemd.io/CONTAINER_INTERFACE/
[1]: https://github.com/systemd/systemd/issues/15101#issuecomment-598607582
[2]:
https://github.com/systemd/systemd/commit/bf331d87171b7750d1c72ab0b140a240c0cf32c3
Signed-off-by: Thomas Lamprecht <t.lampre...@proxmox.com>
---
I hate it.
Just a POC for commenting or picking up, probably belongs in a LXC config or in
a "per distro, per systemd version" specific thing
Could `sys:mixed` be enough?
We might need to explicitly rw-mount /sys/kernel/security for nested apparmor
with either of them.
Since we're effectively reducing access this will surely annoy some users. We probably
want this to be configurable at first at least. We can make it default/opt-out IMO, at
least for archlinux containers, but I don't like the idea of a more "complex"
version check for this.
Sooner or later you need that anyway, we get now already warning for
the v4/v6 DHCP systemd-network settings, they will be dropped in a future
release, but the new variants ("ipv4", "ipv6") are only available since
systemd version v219 or v220, and other settings will surely also get
replaced sometimes in the future.
IMO, a "get CT systemd version" helper allows to differentiate between
old and new methods easily without much hassle.
I suppose so. Need to figure out a *good* way to do that then.
I mean, the single and for me obvious way was to get the systemd binary
by checking common /lib and /usr path(s) and the just do a `systemd --version`
on that..
I'd prefer not to have to execute a guest binary ;-)
Then we need to drop support for CT, because that consist of just executing
guest binaries ;) I'd do it in the CT namespace, if possible.
Duh ;-) it's just that if I can avoid it...
Howabout checking the equivalent of `readelf -d /bin/init`
It's a symlink to /lib/systemd/systemd and links against
libsystemd-shared-245.so
(Taking lxc.init.cmd/lxc.execute.cmd custom settings into account to find the
right init)
Yeah, works OK too, I guess.
The question is now whether to use readelf, just read the symlink and
check for the library in that same folder, or extend our ELF reader... ;-)
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
