[pve-devel] [PATCH container 2/2] update_lxc_config: mount /sys read-only for CONTAINER_INTERFACE comapt

[Thomas Lamprecht]

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.lamprecht at 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.

> 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.