Hi Am Samstag, dem 25.02.2023 um 19:38 +0100 schrieb Ludovic Courtès: > Hello! > > Liliana Marie Prikler <liliana.prik...@gmail.com> skribis: > > > this comes a little late, as Gnome folks have decided that > > evaluating arbitrary Javascript over DBus is perhaps not always the > > wisest idea¹, > > Too bad, what could possibly go wrong? Well, I could imagine a fair number of scenarios from denial of service attacks to privilege escalation. Once you have limited code execution on the target machine, that is – you would need to at least be able to send messages over DBus after all. I'm not sure what the Gnome team has in mind exactly, but in any case, they consider Eval to be a private, rather than public API.
> > Once you set the unsafe flag in Looking Glass and promise to be a > > very good girl, you can now extract environment variables. > > > > $ herd getenv gnome PATH > > > > ;;; (reply #t "\"/gnu/store/s43dhx83c3a2g79vs5anf3wdmv9lwpi3-glib- > > 2.70.2-bin/bin:/run/setuid- > > programs:/home/yuri/.config/guix/current/bin:$HOME/.guix- > > profile/bin:$HOME/.guix-profile/sbin:/run/current- > > system/profile/bin:/run/current-system/profile/sbin\"") > > > > > > If you were naughty and didn't do the magic dance, you get a rather > > unhelpful result instead. > > > > $ herd getenv gnome PATH > > > > ;;; (reply #f "") > > This is super cool and super useful. Is there some way we could > achieve this (getenv/setenv in the GNOME Shell process) without > resorting to JS? Well, we could patch the Gnome Shell DBus API to expose getenv(s), setenv(ss) and unsetenv(s) – note the DBus method signature in brackets. As far as I'm aware, there is currently no such public API. > (💡 Did you know? On GNU/Hurd, each process implements the “msg” RPC > interface, which, among other things, lets you inspect and change its > environment variables! If you have a childhurd running, try > something like: “msgport --getenv=PATH -p $$”.) Sounds fun. > > Provided suitable Fibers integration, we could have services that > automatically start/stop based on some notification received on the > bus (devices plugged/unplugged, power or network condition changes, > etc.). Even better, we could (at some time) go full systemd and take control over all services spawned via DBus. Cheers