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

[Wolfgang Bumiller]

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

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