uidnobody

You're just making stuff up here, the OP was sent abuse firstly by pottering and handled the situation quite professionally by providing a detailed overview of the issue he posted and responding to the maintainers deflections with further information. The OP sent no death threats and posted about his perspectives and technical data on what he sees as a medium risk issue in systemd's pty handling. Why not chown the pty as he suggests, reduce the risk and thank him for giving his time freely on this matter? Conflating the behavior of others against Pottering as somehow someone discussing systemd publicly being responsible is classic DARVO actions. The OP was attacked by pottering, not the other way around.

the op was sent harassing messages and insults by the package maintainer, who are you to demand how and where people discuss security issues? the write up on github is very detailed and identifies a vulnerability added by systemd that can be fixed. Systemd claiming its a victim of abuse and death threats is laughable when they instigated attacks on the OP and his credibility. Calling security researchers grifters for sharing their work is ultimately harmful to users.

OP's advisory on this posted to github https://github.com/hackerhouse-opensource/exploits/blob/mast...

so fix the issue by chown the pty created by systemd and give the OP his dues for pointing the issue out, seems like unnecessary flaming beyond that as to why this can be used to freely hijack root permissions with ptrace_classic and tty ioctls is a wider problem that should also be addressed and protected against when elevating rights. Microsoft "sudo.exe" doesnt have the same issue and fixed an insecure pipe permission quickly that allowed it. As for the boundary policy kit auth for systemd-run is one-shot meaning users should be prompted for each elevation request but looks to be persistent for the lifetime of the elevated process as policy kit is no longer requesting auth when the user does any of the three methods OP outlined.

in the case of systemd the pty remains user owned once the root program is attached, this allows any user process to read and hijack the root program. sudo, su and doas ymmv. The suggested fix for systemd is to chown the slave pty to the user privilege that matches the attached program to prevent misuse.

3rd example, its a pty permission problem as the OP said in his initial post and he suggested a tested fix. https://x.com/hackerfantastic/status/1786485377617846348