See also https://github.com/systemd/systemd/issues/11026
But this isn’t a systemd bug, this is a bug in software systemd relies on.
And it's very unlikely to happen by accident, right? So can't get too excited about this.
Bit of trivia - one some older Unixes (HP-UX) the uid -1 was special - was always unprivileged 'nobody' and was equal to 65535.
Or use a broken / misconfigured AD/LDAP to sync uid/gid across a pool of machines.
I am not so sure about that. I work at a smallish, place and by default my AD account has UID of 945004649. Still under the INT_MAX but not that far off. Our domain controller is running Windows 2012 R2, and nothing was changed or touched regarding UID's, everything was left at the default. We just create users and get whatever UID AD assigns.
But, it turns out this value is, in fact, special in current day Linux as well. It's the default value of the special 'overflow' uid, can be seen/set at /proc/sys/fs/overflowuid.
Apart from some legacy stuff using 16-bit uid's, today it's mostly used for two things
1) In NFS, if mapping a user fails, then it gets assigned the overflowuid.
2) In containers with user namespaces, unmapped users again get the overflowuid.
For more details, see https://lwn.net/Articles/695478/
Thanks for the correction.
I think -2 is just easier to type and stands out more.
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.
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".
Unsigned or signed? That seems to be the critical difference here.
The proposed patch from the systemd developers, somewhat worryingly, apparently does not address the failing open. It simply stops PolicyKit from excluding negative numbers as UIDs, and thus the assertion from failing. The worry is that some other assertion might trigger in the agent, or be introduced, that causes it to fail open in some other way. It should fail closed.
We have been down this road before with assertions.
> unprivileged users with negative UID can successfully execute any systemctl command
Wrong. pkttyagent is just a frontend, it does not do any authorization itself. That's up to polkitd.
# setuidgid sint32maxp1 id
uid=2147483648(sint32maxp1) gid=2147483648 groups=2147483648
# setuidgid sint32maxp1 pkexec id
(process:99600): GLib-GObject-WARNING **: value "-2147483648" of type 'gint' is invalid or out of range for property 'uid' of type 'gint'
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)