Getting "User did not grant permission" on Ubuntu 14.04 no matter what about sudo-prompt

[jorangreef]

Thanks @jviotti

I should have made it clearer, but the Readme (under Behavior) mentions that sudo-prompt should only be used to run non-graphical commands, for the same reason that the sudo command should only be used to run non-graphical commands. There is also a link in the Readme explaining the reason for this.

I think that's why pkexec requires an explicit option in order to run graphical applications, and we rely on that when using the pkexec binary on Linux.

When we use gksudo, we actually pass the sudo-mode option to actively prevent the command being used to launch graphical applications: https://github.com/jorangreef/sudo-prompt/blob/master/index.js#L160

With sudo-prompt I tried to keep the surface area as small and focused as possible, to do one thing well. The idea is that it should mimic sudo and the uses for sudo as much as possible. It's sudo but with a graphical password and that's all.

[jorangreef]

I was thinking we could support passing ENV variables, but the reason for not doing so this far is because I am not sure how much this can be supported across the various sudo binaries we use (and the way in which we use them).

For example, on OS X, we currently set the sudo timestamp using an applet which runs an Apple Script using administrator privileges, and only after that do we call the command using sudo (which then does not require a password because there is an existing session). I am planning on adding support for OS X systems which do not support this (see: #13), by getting the Apple Script to launch a script of the user's command instead, and I am not sure how easy it will be getting ENV variables to work here.

[jviotti]

Hi @jorangreef

Thanks for your response. According to the post you link in the "Behaviour" section, using sudo is not recommended to open graphical applications, but using graphical variants, like gksudo, or kdesudo is ok:

Just be consistent in suggesting good practice: gksudo and kdesudo for graphical applications. sudo for command-line applications.

We use sudo-prompt at https://github.com/resin-io/etcher to provide application-wide elevation in OS X, which works fine (OS X is smart enough to open graphical applications running as sudo in the current graphical session), therefore the ENV workaround should only be necessary on Linux.

We did look into only providing elevation when necessary, however had trouble forking an elevated Electron process in a packaged application given that when packaged, the Electron executable seems to be locked in to running a specific application (the one that is has been packaged with). Do you know a solution to this problem?

[jorangreef]

Yes, gksudo or kdesudo were meant to open graphical applications, but sudo-prompt tries to mimic sudo itself (except for the graphical prompt) and I would like for it to provide the same guarantees as sudo as far as possible.

If we were to support graphical applications, there would be a few more things beyond ENV we might need to do, and it would be difficult to handle all the edge cases for different applications running as root, see: http://askubuntu.com/questions/270006/why-should-users-never-use-normal-sudo-to-start-graphical-applications

We did look into only providing elevation when necessary, however had trouble forking an elevated Electron process in a packaged application given that when packaged, the Electron executable seems to be locked in to running a specific application (the one that is has been packaged with). Do you know a solution to this problem?

By packaged application, do you mean a Linux package, e.g. something distributed through apt-get?

I would try to avoid elevating the entire application if possible. Rather restrict sudo access to the specific shell commands that need it. That should be much safer.

[jviotti]

I see, makes sense.

By packaged application, do you mean a Linux package, e.g. something distributed through apt-get?

Yeah, that's right.

I would try to avoid elevating the entire application if possible. Rather restrict sudo access to the specific shell commands that need it. That should be much safer.

The code that requires elevation is a NodeJS script, with opens a device file for writing purposes. In order to run this script we should call a command with electron or node, e.g: node write.js or electron write.js (with the RUN_AS_NODE setting), however the first one assumes node is installed on the system, and in the second case, the electron binary in the packaged application seems to ignore command line arguments.

[jorangreef]

Thanks, I think I understand a bit better.

Have you checked with @zcbenz regarding the electron binary ignoring command line arguments when packaged?

It would add an extra 9 MB or so, but what about including a node binary with etcher?

[jviotti]

@jorangreef I will. I tested this long ago, so maybe it was an issue that is fixed by now, so I'll give it a go with later versions just in case.

Regarding including node, we thought about it, but we already have lots of complains regarding the application bundle size, so I guess that's not an option for us.

[jviotti]

Yeah, the issue (or feature?) still happens in Electron v0.36.11, in OS X at least.

[jorangreef]

I think the best thing then would be for you to target pkexec directly when on Linux.

[jviotti]

I'll take your suggestion, thanks a lot!