Linux editor and sudo

Midihub Feature Requests
1

I’m a long-time Linux person and don’t particularly like what I see in the Linux version of the editor. It’s the first time I actually see a piece of software that isn’t an installer but a ready-to-run binary, yet presents me with a prompt to enter a password for sudo. Even worse, it does so without giving a reason! I can only guess that the program checks for the presence of the udev rules for the MIDIhub, then wants to become superuser just to install those. This is very confusing and bad practice. More surprisingly, the program runs fine if sudo isn’t installed at all.

I can see the point of having everything needed in a single file, but this behaviour is just very bad practice. My suggestion is that the program doesn’t call sudo except when instructed to. You could place the sudo functionality inside the “Help” menu, or simply add a command-line parameter that enables the udev rules check and the superuser prompt. Even better, if connection fails from within the GUI, a window should pop up telling the user what to do – maybe even just the path and contents of the udev rules file.

2

Hi, here’s the stuff the Linux version of the Editor does on launching the application, in case the udev rules are not installed:

#!/bin/sh

LAUNCHER_ABS_PATH=$(dirname $(readlink -f "$0"))

if [ ! -e /etc/udev/rules.d/50-Midihub-v0.rules ]; then
	echo -n "Installing Midihub udev rules... "

	cat > /tmp/install-midihub-udev-rules <<\EOF2
#!/bin/sh
rm -f /etc/udev/rules.d/50-Midihub-*.rules
cat > /etc/udev/rules.d/50-Midihub-v0.rules <<\EOF
SUBSYSTEM=="tty", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0c9c", MODE="0666", SYMLINK+="midihub_%s{serial}"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="0c9c", MODE="0666", SYMLINK+="midihub%n"
EOF
udevadm trigger
EOF2
	chmod a+x /tmp/install-midihub-udev-rules

	sudo true && sudo /tmp/install-midihub-udev-rules
	sudo true || pkexec --disable-internal-agent /tmp/install-midihub-udev-rules || true

	rm -f /tmp/install-midihub-udev-rules

	echo Done.
fi

exec "$LAUNCHER_ABS_PATH/usr/bin/midihub-editor"

If the udev rules are not installed, it wouldn’t have the permission to communicate with Midihub hardware. It does echo what it’s about to do, but it’s only visible if started from a terminal. Do you have a suggestion for a command to use to show a message on startup? It looks like pkexec does not allow displaying a message.

Having the Linux version of the Editor packaged as an AppImage helps us to have a single build of the editor compatible with as many Linux distributions as possible.

3

Btw, if I remember right, in case you get the GUI prompt, it will say it wants to run /tmp/install-midihub-udev-rules as sudo, so you have a chance to inspect the script and see what will get done.

4

On my computer (Debian) with sudo installed, there was no GUI output, only the sudo password prompt on the console without stating what the superuser access is required for. Without sudo, the udev checks fail and the program runs fine. BTW, there is no pkexec on my system, so even running the program with superuser rights wouldn’t install the udev rules.

In any case, the executable should not run sudo in any situation, that’s just bad practice.

My suggestion is this: The executable should check for the presence of the udev rules when connection to the hardware fails (and at no other time). Then, if the rules aren’t in place, it should dump a message both on the terminal and in the GUI (popup window, maybe). This message should instruct the user to run a command in the terminal, which should look like this:

sudo ./whatever_appImage --install-udev-rules

which makes it quite clear that there is going to be some superuser involvement and also what it’s for. When run this way, the appImage should put the udev rules in place and exit, reporting on the successful installation of the udev rules in a brief message.

This way, the program never calls sudo and therefore never gets a chance to run with superuser privileges without the user knowing.

5

Did you start the Editor by double clicking the executable or through the terminal?

6

I always start it via the terminal.

7

In that case you should have seen the “Installing Midihub udev rules…” message. Running the entire AppImage as sudo is not secure, as the entire software has way more unrelated code to the things that must be performed as super user, including from 3rd party libraries, and is very opaque to the user. sudo should be used only on the minimal subset of commands, as it’s being done right now. The script can also be inspected beforehand by the vigilant user by doing ./MidihubEditor.AppImage --appimage-extract, and looking at the contents of squashfs-root/AppRun, it’s the same as posted above.

I understand that the current behavior may be concerning in case you have recently used sudo and it temporarily remembers the password, then you’d have no chance to react. In the next version, we’ll add a -k argument to the first sudo call, so the user must re-enter his password, or can hit Ctrl+C to stop it.

8

You just persuaded me to remove all instances of sudo from all my computers, I’m not even sure why it was installed, I have no use for it. Remember that many Linux distributions are set up to not even require a password for sudo, so your calls to sudo would actually go unnoticed by users of such.

If you want to do it right without using sudo (either from within the AppImage or for calling it like I suggested), you’ll have to instruct the user to move the correct file into the correct place, then trigger udevadm, both with superuser privileges. The AppImage could write the rules file into a public place (/tmp), so the user would only have to copy the whole file rather than editing it and copy-pasting the contents. It’s still more work, but it’s clean and transparent as well as secure.

So the idea would be to write a file to /tmp, then dump a list of instructions that can be copy-pasted into the terminal that do the superuser part of the work.

The other thing I don’t like is the permissions you give to MIDIhub: 0666 is too permissive, I’d prefer 0660 with the appropriate group (audio or plugdev). That’s really a minor thing, however.

9

We will keep the current design of performing the technical work for the user at startup, we aim for user simplicity where possible. Advanced users still have options to get around the startup script and perform the work themselves.

10

Fair enough. Just one last thing for you to consider: If you do it this way, it would be very nice to at least wait until connection to the MIDIhub fails (when invoked from the menu, not on startup) before doing the sudo stuff. As it currently stands, a regular user on a system with sudo installed is unable to run the editor for offline testing (before purchase, for instance) without entering a password. Luckily for you, I actually tested the editor after ordering the MIDIhub, but if I had tested the software first, I would have stayed clear of the product.

Also, consider removing the dependence on pkexec. I don’t know what it is, none of my computers have it installed, so it can’t be a wide-spread Linux thing.

1 Like
11

Ok, by default we want the Editor to just work, we’ll add and advertise at the prompt an argument ‘–skip-udev-rules-install’ so no sudo / pkexec is necessary.

pkexec is a graphical prompt for running commands in elevated context.

The startup script itself is written on purpose to first attempt using sudo, if that fails, then use pkexec, if that fails, continue to start the editor. If you run it by double-clicking the binary, there’d be no way for ‘sudo’ to ask for the password, so pkexec would take over, if available on the system.

1 Like