prefer pkexec over sudo in PINCE.sh

[notwithering]

this will use pkexec for privilege escalation over sudo, it will still fall back to sudo if pkexec fails (like it not being installed). this should provide a better experience for the user if running through a application runner gui

[brkzlr]

You haven't changed anything for the AppImage which is arguably the only place we actually need this change for as the dev builds are intended for contributors only (and you would use the command line anyway for logging purposes).

You will need to build a correct AppImage runner in the ci/package.sh file so it will also prefer pkexec before sudo.

Another thing to note is the reason we didn't implement this trivial change yet is because we'd like to implement a logger at runtime because if we do a GUI authentication route, users will no longer have a command line open so when they encounter issues, they will have to keep reproducing the issue in a terminal instance to give us the relevant logs.

This can be iffy if it's a low repro bug so we'd want to keep this QoL for us devs by moving the usual terminal output to a logging file if we're to go with polkit.

[notwithering]

You haven't changed anything for the AppImage which is arguably the only place we actually need this change for as the dev builds are intended for contributors only (and you would use the command line anyway for logging purposes).

You will need to build a correct AppImage runner in the ci/package.sh file so it will also prefer pkexec before sudo.

oh alright, the aur package that i use uses PINCE.sh so i didnt know, ill see what i can change

Another thing to note is the reason we didn't implement this trivial change yet is because we'd like to implement a logger at runtime because if we do a GUI authentication route, users will no longer have a command line open so when they encounter issues, they will have to keep reproducing the issue in a terminal instance to give us the relevant logs.

This can be iffy if it's a low repro bug so we'd want to keep this QoL for us devs by moving the usual terminal output to a logging file if we're to go with polkit.

yeah that was another thing i was thinking after i made the pr, a proper logging system would be good so the "scary terminal!" wouldnt have to be visible to the user

[brkzlr]

AFAIK the AUR package modifies PINCE.sh in its own way so it can run. I'm not entirely sure as we don't touch nor maintain the AUR package, they're on their own, but it's worth checking out yourself as the changes you made might be useless without a change in the AUR package.

@korcankaraokcu Shall we require a logging system before we approve this or go ahead and approve once the requested changes are done but deal with some missing logs until a quick dirty logging system can be implemented?

[notwithering]

also im unsure what to change in the appimage, should i change echo "Please run this AppImage using 'sudo -E'!" to auto pkexec or sudo itself?

[brkzlr]

I don't know how pkexec is working as I haven't checked it out yet, but what you want to do is check if the user is running in a privileged state already, if not then you should try to use pkexec to run the PINCE AppImage in an elevated state.
If it fails, then the usual error message should appear.

IIRC I didn't embed sudo in the AppImage due to some issues which is why I opted for the error message to tell users to run the AppImage itself as sudo. I don't know if the same issues will happen with pkexec so you will have to try yourself.

EDIT: Just to confirm, you only have to edit the AppRun.sh creation code, at line 178. You don't need to touch anything else in that package.sh file.

[notwithering]

AFAIK the AUR package modifies PINCE.sh in its own way so it can run. I'm not entirely sure as we don't touch nor maintain the AUR package, they're on their own, but it's worth checking out yourself as the changes you made might be useless without a change in the AUR package.

just checked the PKGBUILD and it uses the PINCE.sh from the repo but removes the .venv/PINCE check so it should work just fine

prepare() {
	# Remove ".venv/PINCE" exist check
	sed -e '/^if \[ ! -d .*.venv.* \]; /,/venv.*activate$/ s/^/# /' \
		-e 's|[^ ]*python3|python3|' \
		-i "./$pkgname/PINCE.sh"
}

I don't know how pkexec is working as I haven't checked it out yet, but what you want to do is check if the user is running in a privileged state already, if not then you should try to use pkexec to run the PINCE AppImage in an elevated state. If it fails, then the usual error message should appear.

IIRC I didn't embed sudo in the AppImage due to some issues which is why I opted for the error message to tell users to run the AppImage itself as sudo. I don't know if the same issues will happen with pkexec so you will have to try yourself.

alright thanks, ill take a look

[notwithering]

@brkzlr having major issues trying to use the package.sh, errors here there and everywhere. i dont think im going to be able to properly test it so what i wanted to try was sudo -E "$0" "$@" then pkexec {ENV_VARS stuff} "$0" "$@" if you wish to try. ill continue fighting this thing to see if i can get it to work

[brkzlr]

If you're in Arch, you have to add export NO_STRIP=1 right before deploytool is called otherwise it will fail during packaging. Add it above line 195.

[notwithering]

If you're in Arch, you have to add export NO_STRIP=1 right before deploytool is called otherwise it will fail during packaging. Add it above line 195.

no, using a linux mint virtual machine with apt. didnt really want to change my install much, getting file permission errors with lrelease and something about GMP and MPFR (missing deps?)

[brkzlr]

Now that there's a proper logging system in-place, there should be no issues converting PINCE over to pkexec instead of sudo.

Any updates with the AppImage conversion? Do you still want to handle this or shall I close this and do it myself?

[notwithering]

@brkzlr sure, ill revisit this

[notwithering]

the ci/package.sh script is pretty rough... after a lot of messing around with it which included making linuxdeploy use an env file to prevent anaconda channels TOS issues, aswell as omitting the gdb compilation process

i was able to get the AppRun.sh to execute (not PINCE itself, but whatever) and started experimenting with escalating python aswell as the appimage itself, but both lead to the same issue, appimage is mounted in a read only FUSE filesystem so neither python nor itself could be executed

below is one of my revisions

# Create main running script
cat > AppRun.sh <<\EOF
#!/bin/bash

export APPDIR="$(dirname "$0")"
export PYTHONHOME=$APPDIR/usr/conda
PYTHON="$APPDIR/usr/bin/python3"
SCRIPT="$APPDIR/opt/PINCE/PINCE.py"

if [ "$(id -u)" != "0" ]; then
	if type pkexec &> /dev/null; then
		# Preserve env vars to keep settings like theme preferences.
		# Pkexec does not support passing all of env via a flag like `-E` so we need to
		# rebuild the env and then pass it through.
		CMD=()
		while IFS='=' read -r key value; do
			[ -z "$key" ] && continue
			value="${value//\\/\\\\}"
			value="${value//\"/\\\"}"
			CMD+=("$key=$value")
		done < <(env)

		pkexec env "${CMD[@]}" "$PYTHON" "$SCRIPT"
	elif type sudo &> /dev/null; then
		# Debian/Ubuntu does not preserve PATH through sudo even with -E for security reasons
		# so we need to force PATH preservation with venv activated user's PATH.
		sudo -E --preserve-env=PATH,PYTHONDONTWRITEBYTECODE "$PYTHON" "$SCRIPT"
	else
		echo "No supported privilege escalation utility found. Please run this AppImage as root manually."
		exit 1
	fi
else
	"$PYTHON" "$SCRIPT"
fi

EOF

what do you think should be done? do the hacky workaround of copying the filesystem to get write perms? or give up and let the user/packagers deal with it?

[brkzlr]

Does pkexec not support running read-only stuff? That sounds weird.

Giving up and letting users/packagers deal with it is not an option as AppImage is supposed to be just download and run.

I'll try to look into pkexec and put some of my findings here to help you with it.

[notwithering]

It's not just pkexec, sudo can't either which is interesting

[notwithering]

and I believe I misspoke multiple times, I don't think its a write issue, it's that FUSE doesn't have exec perms

[brkzlr]

FUSE mounting seems to have an allow_other and allow_root options (more info in man 8 fuse) that seem to affect this.

The problem is that it requires the user editing /etc/fuse.conf to allow it which would be a nono.

Could you try adding these options just to figure out if that's the issue or something else?

[notwithering]

I will look into how other appimages do self escalation later today

[notwithering]

found this beautiful variable $APPIMAGE which appears to do the trick, instead of running from the noexec/nosuid FUSE fs, it runs the same appimage of itself. i still wasnt able to get PINCE running properly because of dependency issues that i dont feel like fucking with python for, so please confirm that this does in fact run pince as root corectly. if alls good, should be fine to merge this

p.s. thinking of fixing up the package.sh, as its pretty difficult to use