gksu has no installation candiate Ubuntu 18.04

[blaggacao]

> sudo apt install gksu
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package gksu is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'gksu' has no installation candidate

Maybe this dependency can be released, it seems not being around in any default debian/ubuntu repository... (18.04)

See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867236

[jmccoy555]

Odd...... It worked for me on Ubuntu Desktop 1804 nightlies when I tried a couple of weeks before it was released. I'm back on the official Raspberry Pi Desktop x86 at the moment though.

[ZanderBrown]

No it has been dropped in 18.04 having been deprecated for years, Debian actually dropped it before Ubuntu and I imagine it will similarly be dropped in the next major Raspbian release.

There are some workarounds using pxexec but the long-term solution is a systemd service + polkit

Idea being the systemd service runs as root in the background whilst the ui runs as the current (non-root) user and uses polkit/dbus to authenticate/communicate with the service

[maxnet]

and I imagine it will similarly be dropped in the next major Raspbian release.

That's for rpi org to decide. Keep in mind that other Pi software like rc_gui doesn't exactly use polkit either.

There are some workarounds using pxexec but the long-term solution is a systemd service + polkit

Problem with pkexec is that that it believes passing environment variables from the current session to the program being executed as root is evil. So it's pretty useless for starting GUI applications as root as the application will not have access to things like DISPLAY and cannot draw anything on the screen.

Idea being the systemd service runs as root in the background whilst the ui runs as the current (non- root) user and uses polkit/dbus to authenticate/communicate with the service

Pretty much every button in piserver requires root. Delete a user, you need root to delete home directory. Add an operating system image, you need root, to be able to set file ownership when extracting OS files. Add a new Pi to the system, you need root, as it needs to regenerate configuration files owned by root. Want to start a chroot shell, that obviously needs root.

Splitting that all up in separate actions being executed in a daemon process is a lot of work, just to comply with someone's security checklist. Will not add any security either, as at the end of the day the user is still able to execute any arbitrary shell command as root from the chroot shell...

[ZanderBrown]

That's for rpi org to decide.

Never said it wasn't but it is extra work when it's no longer packaged upstream

Keep in mind that other Pi software like rc_gui doesn't exactly use polkit either.

True but it also doesn't use gksu either

Problem with pkexec is that that it believes passing environment variables from the current session to the program being executed as root is evil.

Hence temporary but there are some wrappers for passing the variables, alternatively look at how synaptic handles this and has done for years

Splitting that all up in separate actions being executed in a daemon process is a lot of work

Agreed!

just to comply with someone's security checklist.

Well I think we can agree security is important

Other benefits:

• Clear separation of logic & UI
• Support running under Wayland
• Possibility of different config clients, say a CLI interface or python scripting

Will not add any security either, as at the end of the day the user is still able to execute any arbitrary shell command as root from the chroot shell...

But we are discussing the security of the server not the client?

[maxnet]

But we are discussing the security of the server not the client?

We are discussing the configuration GUI.

And how would one start the chroot shell terminal using polkit? I doubt the privileged service has any clean way to spawn a GUI program...

[ZanderBrown]

But we are discussing the security of the server not the client?

We are discussing the configuration GUI.

My point here was the arbitrary commands inside the chroot should only affect the chroot contents i.e. the client os image

And how would one start the chroot shell terminal using polkit? I doubt the privileged service has any clean way to spawn a GUI program...

So currently the chroot terminal is started like this: https://github.com/raspberrypi/piserver/blob/6a95e708cb2f1eb74ae235cb661551bd546cfa46/src/piserver.cpp#L650-L662

Which works because piserver is running as root therefore the terminal emulator is run as root so the shell inside it is root which can run chroot

A solution here of course would be to prefix the -e argument with pkexec so the terminal emulator & initial shell are non-root but chroot will be run as root (albeit with a possible password prompt but a polkit policy could mitigate that)

tl;dr:

/usr/bin/x-terminal-emulator -e pkexec chroot

[maxnet]

My point here was the arbitrary commands inside the chroot should only affect the chroot contents i.e. the client os image

Well, the user can easily run commands to step outside the chroot. Its boundaries are advisory rather than really enforced. https://github.com/earthquake/chw00t

A solution here of course would be to prefix the -e argument with pkexec so the terminal emulator & initial shell are non-root but chroot will be run as root (albeit with a possible password prompt but a polkit policy could mitigate that)

Great. A password prompt by default on every button press inside the GUI, unless creating policies for every action...

[ZanderBrown]

A password prompt by default on every button press inside the GUI, unless creating policies for every action...

Not necessarily, things like gnome-control-centre have an action for 'printer management' that unlocks that page. I expect we could do similar with 'piserver management'.

So "PiServer Config" would open as non-root with limited readonly access, then you would "unlock" it (there is actually GtkLockButton for this purpose) which would throw up the "PiServer Config would like to manage PiSever" permision dialog that would open up everything else

[ZanderBrown]

@maxnet thoughts?

[maxnet]

Eventually, it would not be my decision to make. But I personally don't see sufficient advantage to the end-user, to justify the implementation time.