usbbootgui should not run as root about usbbootgui HOT 10 OPEN

Here is the udev rule I use:

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0a5c", ATTR{idProduct}=="276[34]", GROUP="plugdev"

After applying this and patching out the sudo check in rpiboot, it becomes possible for any user in the plugdev group to load firmwares.

from usbbootgui.

usbbootgui is (optionally) launched when a user logs in to the desktop, with normal user privileges, via
the normal desktop autolaunch mechanisms (xdg-autostart).

Downside would be that usbbootgui would practically always be running, regardless whether user planned to use it that day.

Additionally, the udev rule should be part of the rpiboot package, so that it can function stand-alone
without root privileges.

That does is interesting.
If rpiboot no longer needs root, an alternative could be that we let usbbootgui drop privileges (using setuid() or similar) as soon as it has detected logged-in user.

from usbbootgui.

If memory usage is a concern, a tiny listener daemon could be used to launch the main GUI. However, usbbootgui is itself very small, and all the libraries it uses will be loaded already on a Raspbian desktop.

Spawning it directly from udev isn't really a workable option long term due to the X11 workaround needed. There's no equivalent workaround for Wayland, and it will make supporting app container technologies (Flatpak, Snap etc) extremely difficult too. (And on a slight tangent, at least Snaps also expect that your app honours XDG_DATA_DIRS, which it will set according to the location of the container.)

from usbbootgui.

If memory usage is a concern, a tiny listener daemon could be used to launch the main GUI.

It would be nice if the desktop environment provided something that could take care of such things in a broader sense eventually.
But until such time we have the current stopgap solution.

Yes, it's a small program.
But one small program always running to monitor for Pi zeroes being connected.
A second to look for USB storage being connected.
A 3rd to look for mobile phones being connected to offer to sync photos.
A 4th to sync your car navigation maps.
Look at how many systray icons the average Windows computer has, it adds up, and does not improve startup time.

from usbbootgui.

It does not need to have a tray icon. Look at how USB storage hotplug is handled for an example. Your file manager listens for udisks events on DBus and opens a new window when it receives one. Photo sync is actually handled through the same mechanism, via gvfs-mtp (and I have a WIP firmware which adds MTP capability to the RPi Zero for file sync.)

And besides, usbbootgui already has an "always in the tray" mode. :)

from usbbootgui.

I did some more research on this and it turns out that you can make udev launch usbbootgui diectly inside a user's session if the desktop uses systemd as session init. All you have to do is change:

ENV{SYSTEMD_WANTS}="usbbootgui.service"

to

ENV{SYSTEMD_USER_WANTS}="usbbootgui.service"

and put usbbootgui.service somewhere in the session services, ie /lib/systemd/user instead of /lib/systemd/system. I don't know which init system the PIXEL desktop uses though.

from usbbootgui.

Have you tested that?
And in particular the case that the device is already plugged in before the user is logged in?

from usbbootgui.

I have not tested it. My desktop does not use systemd. The docs say it should work though. :)

If there is no session init then nothing will happen afaik. But isn't that the same thing that will happen with the current system, as there's no X server to display the GUI on? Unless you specifically want it to pop up on the login screen for some reason...

I think a more interesting question is what happens if there is a local desktop user and also a remote desktop user. I suspect that they might both see a popup, but I think that could be fixed with some SEAT magic.

All of this is academic though, if PIXEL does not use systemd...

from usbbootgui.

But isn't that the same thing that will happen with the current system, as there's no X server to display the GUI on?

Nope.
My cookie stealing code is patient, and simply sits back and waits for a user to login on :0

https://github.com/raspberrypi/usbbootgui/blob/master/src/stealcookie.c#L51

from usbbootgui.

Hmm, I see.

I believe that can be done using device units, but I would need to set up a test system to figure out the details.

from usbbootgui.