The PolKit dialog window doesn’t display the entire command being invoked. It should.
Without being able to see what it’s doing, even with context, I’m ultimately accepting it rather blindly:
Agreed - this one’s coming from the upstream project, though, as that command line truncation is defined in the code of pkexec. Some history of this for context (short version - it used to only show the path to the binary!):
For what it’s worth, the project’s repository has migrated since then and is now at GitHub - polkit-org/polkit: polkit (formerly PolicyKit) is a toolkit for defining and handling authorizations. It is used for allowing unprivileged processes to speak to privileged processes.
1 Like
Thanks, @johnandmegh. I’ve mentioned this at one of the relevant migrated GitHub issues:
Their repository is a mess – the formatting for both the Butzilla → GL and GL → GH migrations differ, and most issues have both headers taking at least 30% of each issue’s real estate. They also didn’t regain puppet usernames when they migrated, so ascertaining who posted what is solely possible if the viewer manually correlates each message to its original counterpart.
I’m also surprised that such a significant library would migrate from FreeDesktop’s GitLab instance to GitHub of all things. Usually, it’s the other way around.
Unfortunately, it’s intentional:
This is intentional.
At first, polkit didn’t show any program arguments at all, e.g. just
/bin/bash, which was insatisfactory. It was decided that pkexec should start showing arguments to provide information of what exactly is the user authenticating for. But because some commands, e.g. java environments, can have cmdlines hundreds of characters long, it is truncated so the long cmdline does not flood the entire challenge window, or worse, makes the window obtrusively giant.
I’ve asked whether it can be worked around, as a last-ditch hope.
I’d mark this as the “solution” to the post, but Enable the Q&A plugin in all categories - Fedora Discussion affects here too.
Sounds from the reply like…sort of a chicken-or-egg situation, where polkit developers didn’t build an output because the GUI interface to consume that output didn’t already exist, and desktop environment developers didn’t build a place to consume it because nothing exists yet to populate it.
Probably bias on my end, but it would seem to me like the natural solution would be for pkexec > polkit to also pass something like “command_line_full”, so then GUI interfaces can build something to consume it where appropriate (and there’s actually something there to consume) while keeping the somewhat understandable original use case of the truncated version.
But I am not a developer, I’m sure there’s a lot I’m not understanding 
1 Like
@johnandmegh, that’s no bias - it’s the standard and necessary progression. That PolKit decision makes no sense.
I’ve mostly been consuming structured data from the myriad Windows subsystems for most of my time as a developer. The way that most standard UNIX tools do it instead - with string parsing - is dreadful in comparison. I presume that this is another example of the standard UNIX way of doing things being inflexible because the output isn’t structured in a manner that can be easily extended, because it would otherwise be trivial.