One more point: It's not just polkit. It's actually extremely common for programs to misbehave when invoked with argc == 0. Try it out yourself. Build this p

One more point: It's not just polkit. It's actually extremely common for programs to misbehave when invoked with argc == 0. Try it out yourself. Build this program [1] and run it on random programs in /bin and /usr/bin. Count how many segfault. For me, it's a significant fraction, on both Linux and macOS. (Most of the GNU coreutils print an error and abort; this can be accompanied by a core dump, but I still wouldn't count it as misbehaving. On the other hand, a few utilities act as if the environment variables were passed as arguments, which I'd count as misbehaving even if they don't crash.) Now, the vast majority of those are not setuid, so even if those crashes can lead to arbitrary code execution, that wouldn't be a vulnerability, just a bug.* Of the handful of setuid programs, I actually did get some to crash(!), but the ones I checked are just non-exploitable null pointer accesses (likely because they try to access argv[0] without checking if it exists). Thus, argc==0 is not necessarily a wellspring of vulnerabilities. Things have to line up just right for it to be exploitable. polkit is probably the only commonly-installed setuid binary with a vulnerability of this nature. But I'm sure there are some less-common ones that are vulnerable. And the fact that you can get crashes out of some of the most solid, boring programs that exist, even if they're not exploitable, demonstrates just how rare and poorly-understood argc==0 is. [1] https://gist.github.com/comex/fcd2c329be12f656929b80c4ab15b1dd https://gist.github.com/comex/fcd2c329be12f656929b80c4ab15b1... * On Linux, that is. On macOS, thanks to the entitlements system, there are many binaries where getting code execution could give you extra privileges, though only in rare cases are those privileges truly dangerous.