Automatically elevate to root if necessary

[probonopd]

Despite applying AppImage/AppImageKit#364 in 1ffe5aa we still get

when trying to update an AppImage in a location that the current user has no write rights for (e.g., /opt).

Perhaps @abhay44 can have a look?

[probonopd]

@abhay

I manually compiled with vala
check this : http://tinypic.com/view.php?pic=240ycz5&s=9#.WMBQQlfhU8o

Do you have appimageupdate (the script) on your $PATH? Just compiling the GUI is not enough, you need to do all the steps in the script section of https://github.com/probonopd/AppImageUpdate/blob/master/.travis.yml.

[abhay44]

@probonopd I tried to update a appimage named Darktable. No errors occured for me and the appimage is updated to latest version(2.2.3).Please see this link.Please note that I updated with root authentication only.

[probonopd]

Did you change something in the source code? It does not work for me.

What do you mean by

Please note that I updated with root authentication only.

The point is that if a non-root user tries to update such an AppImage, then AppImageUpdate should try to become root and run the appimageupdate with root permissions, similar to what Etcher does.

[abhay44]

I did not change anything in the source code.Just executed as is.pkexec will by run on opening appimage and you give the root password and then the update starts.It is similar to what Etcher does.

[probonopd]

So here is the more detailed explanation from @jviotti:

We got that question a couple of times already 😀 It’s definitely not very straightforward, but its language/framework independent, so it should work for Qt:

• Our application can behave in CLI mode or GUI mode depending on an environment variable, which is read on the entry point of the app
• Initially, the AppImage is mounted as a normal user
• We then prompt the user for elevation (we use https://github.com/jorangreef/sudo-prompt, but with Qt you can probably interact with polkit directly)
• We then re-execute the same AppImage with root permissions, but this time passing the environment variable that causes the app to behave in CLI mode
• The AppImage is remounted again as root
• The CLI communicates with the GUI using IPC

Check https://github.com/resin-io/etcher/blob/master/lib/child-writer/README.md for the more low level details

So in summary: we mount the AppImage twice: once as the user, and once as root

Regarding the Ubuntu Live CD, sudo-prompt, the module we’re using, checks if it can get sudo access before prompting the user. It can do so on the live CD, so it proceeds straight away

This is exactly what we should implement for AppImageUpdate.

What is their "Child Writer" is most likely the appimageupdate CLI tool for us.

[jviotti]

@probonopd We're very interested in having AppImage updates for Etcher, and glad to hear our current approach matches what you think AppImages should be doing. Is there anything I can contribute with? I'm a bit busy these weeks, but I can allocate time on Fridays to help.

[probonopd]

JvanKatwijk/qt-dab#34 (comment) would also profit from this.

[probonopd]

Please see JvanKatwijk/qt-dab#34 (comment) for a possible solution, more testing on that solution is needed.

[probonopd]

Hi @jviotti it would be great if you could have a look at JvanKatwijk/qt-dab#34 (comment)

[probonopd]

For reference (and searchability), @jviotti at JvanKatwijk/qt-dab#34 (comment):

The way we handle this at Etcher is that first we try to run the command (e.g: /tmp/udev-rules-helper) using sudo -n. The -n means that sudo will behave non-interactively, and thus will not prompt for a password. After the program exits, we check stderr for /sudo: /i. If this matches, then it means that we need to prompt the user for elevation using something like pkexec, if not, then it means that the command actually did run with elevation already, so that's all there is to do. Check https://github.com/jorangreef/sudo-prompt/blob/master/index.js#L11 for details.

[probonopd]

For Arduino, I am using this as part of a custom AppRun/start script which appears to be working for me, at least on Live ISOs (more testing on installed systems needed):

cat > /tmp/roothelper <<\EOoF                                                                                                                                                           
#!/bin/bash                                                                                                                                                                             
cat > /etc/udev/rules.d/50-arduino.rules <<\EOF                                                                                                                                         
SUBSYSTEM=="tty", KERNEL=="ttyUSB[0-9]*|ttyACM[0-9]*", GROUP="users", MODE="0666"                                                                                                       
EOF                                                                                                                                                                                     
udevadm trigger
EOoF
chmod a+x /tmp/roothelper

sudo true && sudo /tmp/roothelper
sudo true || pkexec --disable-internal-agent /tmp/roothelper || true

rm /tmp/roothelper

Intended behavior:

• On Live ISOs, it just becomes root, does its thing, without asking the user
• On installed systems, it asks the user for the root password

[TheAssassin]

Legacy issue in the old code base. Please report if it should occur in the rewrite as well.