Live data from Hacker News

PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

gitlab.freedesktop.org

1–10 of 32 posts

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#3
Particularly worth noting because systemd uses polkit, so certain unprivileged users can do systemctl commands that only admins should be able to do.

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.

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#4
You'd have to be a privileged user to create such high uid user.

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.

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#5

You'd have to be a privileged user to create such high uid user. 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.

Incorrect; nobody was 65534.

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#6

You'd have to be a privileged user to create such high uid user. 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.

Was the special treatment of -1 intended by the developers, or did somebody mix up signed -1 with unsigned 65535?

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#7
post #5

You'd have to be a privileged user to create such high uid user. 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.

Incorrect; nobody was 65534.

D'oh! I knew I'd get it wrong.

Thanks for the correction.

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#8

You'd have to be a privileged user to create such high uid user. 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.

> You'd have to be a privileged user to create such high uid user.

Or use a broken / misconfigured AD/LDAP to sync uid/gid across a pool of machines.

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#9
post #6

You'd have to be a privileged user to create such high uid user. 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.

Was the special treatment of -1 intended by the developers, or did somebody mix up signed -1 with unsigned 65535?

See above - it was -2 or 65534.

I think -2 is just easier to type and stands out more.

Re: PolicyKit: Users with UID greater than INT_MAX can execute any systemctl command

#10
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).

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".

Post reply on HN