Particularly worth noting because systemd uses polkit, so certain unprivileged users can do systemctl commands that only admins should be able to do.<p>See also <a href="https://github.com/systemd/systemd/issues/11026" rel="nofollow">https://github.com/systemd/systemd/issues/11026</a><p>But this isn’t a systemd bug, this is a bug in software systemd relies on.
You'd have to be a privileged user to create such high uid user.<p>And it's very unlikely to happen by accident, right? So can't get too excited about this.<p>Bit of trivia - one some older Unixes (HP-UX) the uid -1 was special - was always unprivileged 'nobody' and was equal to 65535.
It should be noted that with a UID larger than INT_MAX a lot of things will start to break, ext4 for example only supports 32bit UIDs, so you won't be able to chown any files as this UID (atleast my own experimentation seems to find this. NFSv4 allows it if you enable squashing/mapping of user ids).<p>Lots of other tools will likely break in similar and unpredictable ways if your UID becomes that high. Likely those ways are also a lot of fun.<p>Since you'd need to be a privileged user to begin with, this is on the same alarm level as "running sed with sudo allows you to edit /etc/sudoers and gain full sudo privilege".
Why don't we have hardware overflow traps? Most numbers should never overflow. We would need just 1 additional bit for arithmetic instructions to indicate that overflows are fine in some cases.
Has anyone found a clean way to remove polkit once installed without breaking systemd? On Redhat at least, you have to kickstart the machine without anything that pulls it in. It can't be "disabled" without breaking things and udev will trigger it regardless of the unit file state.