From: Lennart Jablonka <humm@ljabl.com>
Subject: Re: firefox spawns native helpers without environment
To: Landry Breuil <landry@openbsd.org>, ports@openbsd.org
Date: Tue, 2 Apr 2024 09:11:14 +0000

Quoth Landry Breuil:
>Le Thu, Mar 28, 2024 at 02:52:52PM +0000, Lennart Jablonka a écrit :
>> I’m trying to get himitsu-firefox¹ working on OpenBSD.  It’s a Firefox
>> extension that talks to a daemon² using “native messaging”: The extension
>> calls runtime.connectNative(); the browser spawns a himitsu-firefox-native
>> process, and extension and native process exchange JSON messages.
>>
>> The native process wants to talk to the daemon using the daemon’s socket in
>> $XDG_RUNTIME_DIR/himitsu.  Problem is, the himitsu-firefox-native process’s
>> environment is empty—it doesn’t get no XDG_RUNTIME_DIR variable, or any
>> other one.
>>
>> How come?  Is that documented somewhere?  Can I change that somehow?
>
>you can look with ktrace -i to figure out the env passed to the
>subprocess when it's spawned (look for the execv call)

As far as I can tell, the ktrace doesn’t actually include the 
environment.  This is the exec syscall:

	60933 firefox-esr CALL  execve(0xeea86ca88d0,0xeea4ed16160,0xeea61f97550)
	60933 firefox-esr NAMI  "/usr/local/libexec/himitsu-firefox-native"
	60933 firefox-esr ARGS
	       [0] = "/usr/local/libexec/himitsu-firefox-native"
	       [1] = "/usr/local/lib/mozilla/native-messaging-hosts/himitsu.json"
	       [2] = "himitsu@drewdevault.com"
	98832 firefox-esr RET   sched_yield 0
	60933 himitsu-firefox-native NAMI  "/usr/libexec/ld.so"
	60933 himitsu-firefox-native RET   execve JUSTRETURN

But I can tell himitsu-firefox-native to dump the environment when 
started to a file.  That’s how I found it’s empty.

>- are you sure the himitsu-firefox-native process is spawned at all ?

Yes.  And with a little setenv("XDG_RUNTIME_DIR", "...") at the 
start of himitsu-firefox-native, it works perfectly.

>- compare what happens with a 'known working' other native messaging
>  thing. i've personally tested none, but i think ppl use
>keepassxc-proxy with some browsers. Given the README in
>https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/security/keepassxc/pkg/README?rev=1.6&content-type=text/x-cvsweb-markup
>you might want to locally have to do similar things.

Yes, I had to unveil a few paths.

As far as I can tell, the only thing left for me to try is to look 
at what happens in Firefox with a debugger, though I’d rather not.