Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Probably never for package based distros. I could see it happening for image based distros, where systemd is slowly but surely providing all the building blocks for. It has had the option for `NoNewPrivileges=` in the `system.conf` since v239, so it isn't exactly difficult to disable for the entire system.

Though you'd be surprised how many binaries are suid binaries while they probably shouldn't be (passwd, mount, groupmems, ...), though alot can also work without being suid just more resticted in what they can do.



With https://github.com/thkukuk/account-utils (not the default yet), it's meanwhile possible to run openSUSE Tumbleweed (package based) with NoNewPrivileges= as usual.


> how many binaries are suid binaries while they probably shouldn't be (passwd

I would expect an unprivileged user to be able to change their own password. How else would that work?


Send a message to a socket-activated daemon running as a UID with write access to the password database.


Isn't the issue in this case caused not by suid, but by a daemon running as root reading files from a tmp dir? Seems like a socket-activated daemon wouldn't solve this specific case.


> How else would that work?

Windows way is to have a privileged service which the non-privileged user application talks to over sockets or similar.


systemd-homed stores most of the user specific information in the home directory `~/.identity`, but since the file contents have to be signed the changes need to be done though a daemon, which is talked to via IPC (homectl does the talking to systemd-homed).




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: