3 ms·

The fix for this ("if (argc < 1) exit(126)" [1]) is just ... ugh. Some weeks ago I wanted to run a game; it showed an error when starting that it failed to set

The fix for this ("if (argc < 1) exit(126)" [1]) is just ... ugh. Some weeks ago I wanted to run a game; it showed an error when starting that it failed to set real-time priority for the audio thread, resulting in actual audio stuttering. ALAudio asks rtkit, rtkit asks polkit, and that somehow fails. Why? Who knows. To even figure this out I had to recompile rtkit with some strategic printf() calls in there, because it just doesn't show at all why it failed. Same for polkit. I never did find out what the problem was. I just gave up after a while. It's stuff like this why I dislike all these tools: it all works when it works, but when it fails it really makes your life hard. Here, too, it just exits with 126, no message, and good luck to you as developer or user if something goes wrong. Call me a radical traditionalist unix greybeard, but I really think tools should tell users what goes wrong, even (or perhaps especially) when they're "internal" tools like this, because this it's just really hard to figure out what the problem is. "fprintf(stderr, "too few arguments\n")" is not very hard, it seems to me shrug. [1]: https://gitlab.freedesktop.org/polkit/polkit/-/commit/a2bf5c9c83b6ae46cbd5c779d3055bff81ded683 https://gitlab.freedesktop.org/polkit/polkit/-/commit/a2bf5c...

yrro 5y ago
In case helpful for you or anyone else, you can find out whether polkit would allow a request for an action with pkcheck(1), for instance: "pkcheck --action-id org.freedesktop.RealtimeKit1.acquire-real-time --process $$" and check the exit status. What is missing in all these complaint threads (and this isn't aimed at you specifically) is the complainers' proposed alternatives. It's very easy to write a glib comment about "sudo already does this" "groups already do this" which indicates only that the person writing the comment doesn't understand the problem that PolKit is trying to solve.
- Beltalowda 5y ago
  As near as I could figure out RTkit asked Polkit "do I have permissions to set this real-time?", and Polkit said "no". But perhaps I'm wrong; I found it all very hard to debug as mentioned before, and I didn't care that much just to play some game. I don't have the game on my laptop any more; I'll have to try your pkcheck command next time (although that still won't fix anything, but might get me closer; thanks!) What I lament is not so much that things have changed, but that things have changed in ways I no longer understand or can debug. Back in the Old Days™ you could more or less understand your entire system from a few very basic principles. If something didn't work, you could go in there and usually figure it out on your own. Not that I have rose-coloured glasses about the Old Days™. I remember having to run that horrible "xfree86 -configure" thing when I was starting out with this whole Linux thing. Clearly, things are better now because the last time I had to look at "configuring X" is so long ago I don't even remember how to do it (or even what that filename was; /etc/x.conf? Or /etc/x11.conf? Not sure). I don't think it has to be like this. Just because "su" and "sudo" aren't sufficient and the concepts in e.g. Polkit are good doesn't mean the implementation of these concepts also is.
  - yrro 5y ago
    As they say, change is the only constant. I won't say PolKit's implementation is the best ever. But it exists, and solves real problems, enough so that applications choose to use it and distros choose to ship it. One thing I can say in PolKit's favour is that it's well documented--which is important for such a critical component.
tptacek 5y ago
The only way that condition happens is if the program is being exploited. You cannot, for instance, trigger it from a shell. Here, argc is less than 1. There have been multiple attempts to get the kernel to EFAULT when execve() is called this way, because a NULL argv has utility principally as a gadget in shellcode and nowhere else. EFAULT is what FreeBSD and OpenBSD do when you try to execute a program with a NULL argv. Fault them for not changing the loop, which has clearly busted logic, and adding a guard clause instead. But you can't fault them for not providing a user friendly error to shellcoders. The condition here isn't simply "too few arguments".
- Beltalowda 5y ago
  Can't you exec() this and run it with zero arguments? Either way: when in doubt, best to print a message! You're right this specifically probably isn't the biggest issue, but in general it seems to be design with "this should never happen, just exit/deny" in mind, and turns out that in some odd cases those things do happen.
  - tptacek 5y ago
    No, you can't. Again: argc is less than 1. There is no point to a message here.
    - Beltalowda 5y ago
      This results in an argc of 0 in the a.out program: char* args[] = {NULL}; execv("./a.out", args); If someone did this by accident (as it's a programming error) then they should be told, instead of the unhelpful exit. That's my point.
      - tptacek 5y ago
        The point of exit codes is that they're straightforward for programmers to extract, rather than error messages, which require the programmer to capture and parse stderr. So, no, I don't think you've rescued this very bad argument.
pas 5y ago
> works when it works, but when it fails it really makes your life hard. Here, too, it just exits with 126, no message, and good luck to you as developer or user if something goes wrong. strace Nowadays I just reach for it immediately. Powerful, total/complete (since syscalls are everything). The typical unix tools all depend on these hard to discover environment things. Other processes, env vars, files here or there, sockets, dbus, signals...

yrro 5y ago

In case helpful for you or anyone else, you can find out whether polkit would allow a request for an action with pkcheck(1), for instance: "pkcheck --action-id org.freedesktop.RealtimeKit1.acquire-real-time --process $$" and check the exit status. What is missing in all these complaint threads (and this isn't aimed at you specifically) is the complainers' proposed alternatives. It's very easy to write a glib comment about "sudo already does this" "groups already do this" which indicates only that the person writing the comment doesn't understand the problem that PolKit is trying to solve.

Beltalowda 5y ago
As near as I could figure out RTkit asked Polkit "do I have permissions to set this real-time?", and Polkit said "no". But perhaps I'm wrong; I found it all very hard to debug as mentioned before, and I didn't care that much just to play some game. I don't have the game on my laptop any more; I'll have to try your pkcheck command next time (although that still won't fix anything, but might get me closer; thanks!) What I lament is not so much that things have changed, but that things have changed in ways I no longer understand or can debug. Back in the Old Days™ you could more or less understand your entire system from a few very basic principles. If something didn't work, you could go in there and usually figure it out on your own. Not that I have rose-coloured glasses about the Old Days™. I remember having to run that horrible "xfree86 -configure" thing when I was starting out with this whole Linux thing. Clearly, things are better now because the last time I had to look at "configuring X" is so long ago I don't even remember how to do it (or even what that filename was; /etc/x.conf? Or /etc/x11.conf? Not sure). I don't think it has to be like this. Just because "su" and "sudo" aren't sufficient and the concepts in e.g. Polkit are good doesn't mean the implementation of these concepts also is.
- yrro 5y ago
  As they say, change is the only constant. I won't say PolKit's implementation is the best ever. But it exists, and solves real problems, enough so that applications choose to use it and distros choose to ship it. One thing I can say in PolKit's favour is that it's well documented--which is important for such a critical component.

tptacek 5y ago

The only way that condition happens is if the program is being exploited. You cannot, for instance, trigger it from a shell. Here, argc is less than 1. There have been multiple attempts to get the kernel to EFAULT when execve() is called this way, because a NULL argv has utility principally as a gadget in shellcode and nowhere else. EFAULT is what FreeBSD and OpenBSD do when you try to execute a program with a NULL argv. Fault them for not changing the loop, which has clearly busted logic, and adding a guard clause instead. But you can't fault them for not providing a user friendly error to shellcoders. The condition here isn't simply "too few arguments".

Beltalowda 5y ago
Can't you exec() this and run it with zero arguments? Either way: when in doubt, best to print a message! You're right this specifically probably isn't the biggest issue, but in general it seems to be design with "this should never happen, just exit/deny" in mind, and turns out that in some odd cases those things do happen.
- tptacek 5y ago
  No, you can't. Again: argc is less than 1. There is no point to a message here.
  - Beltalowda 5y ago
    This results in an argc of 0 in the a.out program: char* args[] = {NULL}; execv("./a.out", args); If someone did this by accident (as it's a programming error) then they should be told, instead of the unhelpful exit. That's my point.
    - tptacek 5y ago
      The point of exit codes is that they're straightforward for programmers to extract, rather than error messages, which require the programmer to capture and parse stderr. So, no, I don't think you've rescued this very bad argument.

pas 5y ago

> works when it works, but when it fails it really makes your life hard. Here, too, it just exits with 126, no message, and good luck to you as developer or user if something goes wrong. strace Nowadays I just reach for it immediately. Powerful, total/complete (since syscalls are everything). The typical unix tools all depend on these hard to discover environment things. Other processes, env vars, files here or there, sockets, dbus, signals...