Systemd 246 Released With Many Changes

[phoronix]

Phoronix: Systemd 246 Released With Many Changes

Systemd 246 is out today as the newest version of this dominant Linux init system and system/service manager. Systemd 246 has a lot of new functionality in time for making it into at least some of the autumn 2020 Linux distributions...

http://www.phoronix.com/scan.php?page=news_item&px=systemd-246-Released

[tildearrow]

Typos:

- Tmpfs mounts automatically created by systemd such as for /tmp and /run whill now have a limit of 50% of RAM for /tmp and /dev/sdm while 10% of RAM for other mounts.

Systemd-homed can also support unlocking home directories using FIOD2 security tokens.

[herman]

- A change from Microsoft that will now expose some host OS information to containers.

Microsoft still being Microsoft I see.

[onlyLinuxLuvUBack]

Hold my torch...

[nsklaus]

"Systemd 246 is out today as the newest version of this dominant Linux init system.."

"dominant" --> anti-linux-like hydra monster spreading like a virus, tying itself onto system components like a python is constricting its prey, removing the freedom of choice from the user and thus denaturing linux from its base philosophy.

there, i've fixed it for you.

[jacob]

I wonder if we'll het these goodies in Ubuntu 20.10?

[ssokolow]

Microsoft still being Microsoft I see.

Wasn't that change intended so you could make one containerized build that would call Azure or Amazon or Google cloud services or fall back to something else, depending on which cloud it was running in?

(Not saying I think it's the right way to go about it, which I don't, but I think that was their thought process.)

[skeevy420]

I wonder if we'll het these goodies in Ubuntu 20.10?

It wouldn't surprise me at all if 20.10 gets it. Their feature freeze is on August 27th so this still has a chance to make it in.

[skeevy420]

Wasn't that change intended so you could make one containerized build that would call Azure or Amazon or Google cloud services or fall back to something else, depending on which cloud it was running in?

(Not saying I think it's the right way to go about it, which I don't, but I think that was their thought process.)

"We find ourselves in a situation where application running containerized (specifically as portable services, although this issue is general) need to either find information about the host, or alter their behaviour depending on the host's flavour."

Is what was reported earlier. I don't think there is anything nefarious behind it. Possibly needing to know if the host OS is new enough to do some task doesn't seem all that evil.

[herman]

Wasn't that change intended so you could make one containerized build that would call Azure or Amazon or Google cloud services or fall back to something else, depending on which cloud it was running in?

(Not saying I think it's the right way to go about it, which I don't, but I think that was their thought process.)

Is what was reported earlier. I don't think there is anything nefarious behind it. Possibly needing to know if the host OS is new enough to do some task doesn't seem all that evil.

I'm sure their intentions are to make their life much easier, but as Phoronix noted in a previous article, there is a risk for more exploitation when containers are allowed to learn information outside of itself. It defeats the purpose of having containers in the first place. Microsoft appears not to be able to program without opening everything up.

Granted, exposing more host details to guests/containers can open up the system to potentially easier (more efficient/straightforward) exploit paths and that if some container images become too catered towards specific hosts it may make the containers less robust. ~ Phoronix