There were talks a few years ago about changing sd-tmpfiles name but it was decide not worth it due to the churn and bikeshedding it would cause.
sd-tmpfiles is generally used to create, modify (e.g. permissions) and remove directories on the system. The home.conf is intended for systems that only ship /usr/ (e.g. containers) to create /home/ and /srv/ as a separate subvolume on btrfs
which definitely seems out of scope.
Doesn’t seem out of scope for a system and service management suite. Like, the timeperiod where systemd was “just an init” was relativly brief (like half a year).
They should test this much more often and frequently. Unlike Gnome, KDE do actually care about their users, not just about themselves.
It’s not like GNOME is the only outlier here (for the specific icon problem sure), someone on the linux subreddid also posted this screenshot https://imgur.com/a/1ELtsJb. It seems to really just be that KDE apps kinda struggle out side of KDE. And most of the GNOME devs do care about the users as well, just they also care that their apps look as intended.
It’s been a thing I personally have been wondering why this is how it is for a while. Personally I like most of the GNOME stuff, but this decision has always stood out as odd.
But then again I almost always use ctrl+w or alt-f4 to close apps, so I am mostly unaffected.
doas is relativly simple (a few hundred LOC), especially compared to sudo. The main benefit of run0 over doas is that it isn’t a SUID binary, they are similary complex.
I don’t understand how this is any improvement over pkexec
That has the same problem as sudo: the SUID bit is set for it.
The fact that run0 uses polkit is more of a byproduct that this kinda authentication is already done with polkit all over the place in systemd. You can have individual subcommand accessible to different users (for example everyone can systemctl status, but systemctl reboot needs to be in the wheel group) which is why its generally used within systemd already. And it wouldn’t surprise me if again you can do it with this as well, limiting what commands can unconditionally run, need prompt or are completely blocked.
I don’t know, unless I personally allow the admin to have that kinda access to my files I wouldn’t really want it. And for that case you can enroll recovery keys (which would need to be manually stored, but still) or a fido token or whatever other supported mechanism there is, its LUKS2 backed encryption after all. Then there is also the possibility to just not encrypt the home directory at all.
systemd-run, which is calling into PID1)dlopened on demand (which was planned even before the attack, which is speculated that the attack was accelerated in timeline because he was on a timer before the change was released)This isn’t exactly a “new” attack surface, so removing the attack surface that sudo (and alternatives) is, is probably a net positive.
it does its authorization with polkit (which IIRC defaults to allow all wheel group members) and giving users that shouldn’t be allowed root access, root access, is not something you ever want. This is usually referred to as unauthorized privilege escalation. Also, it isn’t like sudo doesn’t need configuration.
One way to notice a person has “systemd derangement syndrome” is by looking at how they write systemd: if they write it SystemD they are already in late stages of SDS and it isn’t curable anymore.
homed isn’t exactly a home directory replacement, more of an extension. You can mix and match homed and normal home directories like you want (on a per-user basis at least, not within a single user). It does have some nice things, such as user-password based encryption of the home directory, so the password is required to unlock it (no admin access) or automatically using subvolumes on btrfs.
The thing with this is: its just a symlink to the systemd-run binary, which talks to PID1 to spawn new processes (in separate cgroups IIRC). Its one of the most fundamental parts of systemd. Even the debian systemd package includes systemd-run.
I guess the other question is if some tools the distro provides might switch to supporting it by default. For example on Arch there is makepkg that should never be executed as root, but does internally call some things with elevated privileges (mostly pacman to install and remove packages). Currently it checks for sudo and if not falls back to su, but maybe it might be worth considering changing su for run0 if its guaranteed to be there.
The EU already has one for anyone interested https://social.network.europa.eu
I don’t really bother with AV on my linux system. What I do is just use trusted software from my repos and run containerized applications.
What I am currently working on is using secure boot with a Unified Kernel Image (already doing that) that boot into a read-only /usr/ partition with verity + signature (one UKI only loads a certain partition with a specific signature, or nothing at all). Any other things I need I create a systemd sysext that gets overlayed ontop of /usr/ (also read-only) or they get installed as flatpak. For development I would just be using nspawn containers and podman/OCI containers for services that are outside of the other scopes.
This is all based on https://0pointer.net/blog/fitting-everything-together.html which is a nice write down of what I am doing/following.
That already covers a lot of different attack vectors by just not having my system be modifyable outside of my control or apps just being containerized.
The thing with Wayland and X11 is: this couldn’t really be done because of how fundamentally broken incompatible X11 is (and there is XWayland for most clients that mostly works)
Arch: Move more of the things shipped by the distro to /usr/, too many things are still in /etc/, /var/ and /srv/. Generally this isn’t a problem, but when you want to make an A/B updated image where only /usr/ is shipped it is a bit annoying. Also, bash has no way to have a “distro” version of /etc/profile.
Another benefit is: no .pacnew files in /etc/ (or anywhere else) since those would all be managed by the system maintainer and aren’t touched by the package manager
Those benchmarks under “Upstream” does not include esync/fsync from my understanding
Accent colors are coming with GNOME 47.