Custom URL handlers and fireurl

[kmk3]

Background

Currently, some non-browser-related programs (such as email clients) are unable
to open URLs through Firefox. To work around this, access to
~/.mozilla/firefox/profiles.ini and/or to opening Firefox through D-Bus was
added to some profiles, but sometimes that is not enough (see also #5566).

As an alternative method, it has been suggested to write to and read from a
socket to open URLs. Example workflow using "url-writer" and "url-reader":

• Set the url-writer as the default browser somehow
• Run firejailed program
• Firejailed program tries to open a URL, by running url-writer $url
• url-writer writes to the socket
• url-reader (from outside of the sandbox) reads from the socket and opens
  the URL in the desired browser (and/or performs any other desired action)

The benefit of this approach is that it does not require allowing access to
D-Bus nor making profiles less restrictive to allow opening Firefox (or any
other web browser).

Implementation

If the functionality is handed off to an optional external tool called at
runtime, the main benefits are that the tool is fully responsible for all of
its own code/build complexity and dependencies and that this is transparent to
firejail (and to the program that would run it). The downside is that the user
might need to install a separate tool (and that this requirement might not be
obvious).

With regards to adding fireurl to this repository (as mentioned in #5574),
the main concerns from the following comment also apply to it:

• Rewrite parts of firejail in Rust #4386 (comment)

Besides that, I think that it would be more fitting to deal with such
simple/highly customizable tasks in a more scripting-oriented language.

For example, here are shell script implementations of a URL writer and reader:

url-writer

#!/bin/sh
# url-writer

set -e

test -z "$XDG_RUNTIME_DIR" && XDG_RUNTIME_DIR="/run/user/$(id -u)"
test -z "$MYSOCKET" && MYSOCKET="$XDG_RUNTIME_DIR/mysocket"

if test ! -e "$MYSOCKET"; then
	printf 'Creating socket at %s...\n' "$MYSOCKET"
	mkfifo "$MYSOCKET"
fi

url="$1"

printf '%s\n' "$url" >"$MYSOCKET"

url-reader

#!/bin/sh
# url-reader

set -e

test -z "$XDG_RUNTIME_DIR" && XDG_RUNTIME_DIR="/run/user/$(id -u)"
test -z "$MYSOCKET" && MYSOCKET="$XDG_RUNTIME_DIR/mysocket"

if test ! -e "$MYSOCKET"; then
	printf 'Creating socket at %s...\n' "$MYSOCKET"
	mkfifo "$MYSOCKET"
fi

printf 'Searching for a web browser...\n'
if test -n "$BROWSER"; then
	: # already set
elif command -v xdg-open >/dev/null; then
	BROWSER=xdg-open
elif command -v x-www-browser >/dev/null; then
	BROWSER=x-www-browser
elif command -v firefox >/dev/null; then
	BROWSER=firefox
else
	printf 'error: no web browser found (try setting BROWSER)\n' >&2
	exit 1
fi

printf 'Found web browser: %s\n' "$BROWSER"
printf 'Reading socket %s...\n' "$MYSOCKET"

while true; do
	while read -r url; do
		printf 'URL: %s\n' "$url"
		$BROWSER "$url"
	done <"$MYSOCKET"
done

Note: I'm not 100% sure about the order used when searching for a web browser.

Note2: x-www-browser is looked up by xdg-open IIRC.

Another example, using the same executable names and paths as fireurl
v0.1.0:

fireurl

#!/bin/sh
# Alternative to https://github.com/rusty-snake/fireurl

set -e

test -z "$XDG_RUNTIME_DIR" && XDG_RUNTIME_DIR="/run/user/$(id -u)"
FIREURL_DIR="$XDG_RUNTIME_DIR/fireurl"
FIREURL_SOCKET="$XDG_RUNTIME_DIR/fireurl/fireurl0"

mkdir -p "$FIREURL_DIR"
if test ! -e "$FIREURL_SOCKET"; then
	printf 'Creating socket at %s...\n' "$FIREURL_SOCKET"
	mkfifo "$FIREURL_SOCKET"
fi

url="$1"

printf '%s\n' "$url" >"$FIREURL_SOCKET"

fireurld

#!/bin/sh
# Alternative to https://github.com/rusty-snake/fireurl

set -e

test -z "$XDG_RUNTIME_DIR" && XDG_RUNTIME_DIR="/run/user/$(id -u)"
FIREURL_DIR="$XDG_RUNTIME_DIR/fireurl"
FIREURL_SOCKET="$XDG_RUNTIME_DIR/fireurl/fireurl0"

mkdir -p "$FIREURL_DIR"
if test ! -e "$FIREURL_SOCKET"; then
	printf 'Creating socket at %s...\n' "$FIREURL_SOCKET"
	mkfifo "$FIREURL_SOCKET"
fi

printf 'Searching for a web browser...\n'
if test -n "$BROWSER"; then
	: # already set
elif command -v xdg-open >/dev/null; then
	BROWSER=xdg-open
elif command -v x-www-browser >/dev/null; then
	BROWSER=x-www-browser
elif command -v firefox >/dev/null; then
	BROWSER=firefox
else
	printf 'error: no web browser found (try setting BROWSER)\n' >&2
	exit 1
fi

printf 'Found web browser: %s\n' "$BROWSER"
printf 'Reading socket %s...\n' "$FIREURL_SOCKET"

while true; do
	while read -r url; do
		printf 'URL: %s\n' "$url"
		$BROWSER "$url"
	done <"$FIREURL_SOCKET"
done

In either case, they do not require any tooling other than a POSIX shell, while
also being relatively easy to customize and maintain.

Custom Handlers

Regardless of any given implementation, keep in mind that standalone custom URL
handlers are already a thing (independently of firejail) and that there are
multiple different actions that a user might want to take when a program tries
to open a URL, for example:

• Show it in a notification (such as with notify-send)
• Copy it to the clipboard (using xsel/xclip/wl-clipboard)
• Open it in a given browser (which could be chosen through dmenu)
• Append it to a file
• Suggest any of the above actions in dmenu

(The same goes for custom xdg-open-like scripts that forward the argument to
different programs depending on what file extension it contains, for example)

I haven't looked into this in a while, but last I checked it was my impression
that users creating their own custom URL handlers was not too uncommon,
especially considering that performing the above actions in shell scripting is
trivial (as it just requires gluing a few different programs together).

So I wonder if there are common tools/paths used for this which we could
leverage.

Ideally they would all use a standardized program name and socket path (so that
we would only have to worry about those in the profiles).

But if there isn't anything fitting, then I suppose that using a fireurl
executable and ${RUNUSER}/fireurl path would make sense.

Which Browser

There is also the issue of how a given program may try to determine what is the
default web browser (which may vary between different programs), and how easy
it would be to convince all applicable programs to use something like fireurl,
though this issue might warrant its own discussion.

---

Relates to:

• [meta] Opening links outside of the sandbox #6462

[glitsj16]

Thank you @kmk3 for gathering the related info regarding this topic.

In relation to the Background section I've nothing to add. I think it's clear that a solution that keeps sandboxes as tight as possible would be preferable.

Regarding the Implementation side I can understand much better now why some reservations were raised earlier. Both url-writer and url-reader look fine to me and the fact that simple POSIX shell scripting is used is definately a plus.

Set the url-writer as the default browser somehow

There is also the issue of how a given program may try to determine what is the
default web browser (which may vary between different programs), and how easy
it would be to convince all applicable programs to use something like fireurl,
though this issue might warrant its own discussion.

If I understand correctly the socket approach needs one part inside the sandbox and the counterpart runs outside of this. In that context I don't see much difference between fireurl/fireurld (from @rusty-snake or as rewriten here in POSIX shell by @kmk3) and url-writer/url-reader.

I do have a question about how the handling web browser is determined in the POSIX shell fireurld version and url-reader in their above state. If URL handling should be offered in Firejail, shouldn't hyperlinks get relayed to a firejailed web browser? If so, perhaps the checks could be made against available (firecfg-made) symlinks in /usr/local/bin instead?

There is also the issue of how a given program may try to determine what is the
default web browser (which may vary between different programs), and how easy
it would be to convince all applicable programs to use something like fireurl,
though this issue might warrant its own discussion.

Yes, that's a valid point. FWIW I've seen applications using:

• gio
• gvfs
• xdg

Each of these tools has commands to query/set the default handlers for text/html and/or x-scheme-handler/http{,s}, so there's a few things we could build on.

[kmk3]

@glitsj16 on Jan 13:

Thank you @kmk3 for gathering the related info regarding this topic.

In relation to the Background section I've nothing to add. I think it's
clear that a solution that keeps sandboxes as tight as possible would be
preferable.

Regarding the Implementation side I can understand much better now why some
reservations were raised earlier. Both url-writer and url-reader look fine to
me and the fact that simple POSIX shell scripting is used is definately a
plus.

No problem; glad it made sense :)

Set the url-writer as the default browser somehow

There is also the issue of how a given program may try to determine what is
the default web browser (which may vary between different programs), and
how easy it would be to convince all applicable programs to use something
like fireurl, though this issue might warrant its own discussion.

If I understand correctly the socket approach needs one part inside the
sandbox and the counterpart runs outside of this. In that context I don't see
much difference between fireurl/fireurld (from @rusty-snake or as rewriten
here in POSIX shell by @kmk3) and url-writer/url-reader.

Yes, all of the listed implementations should work similarly.

I just used generic names in the examples to make it clearer what each part
does.

I do have a question about how the handling web browser is determined in the
POSIX shell fireurld version and url-reader in their above state. If URL
handling should be offered in Firejail, shouldn't hyperlinks get relayed to a
firejailed web browser? If so, perhaps the checks could be made against
available (firecfg-made) symlinks in /usr/local/bin instead?

In that regard I don't think that the implementation matters as much as how
fireurld is started. If the environment is setup correctly, then it should
work the same way as when trying to open the browser normally.

For example, using Firefox as the browser, there are multiple ways to try to
ensure that it runs through firejail:

• Setting $BROWSER to firefox
• Making sure that /usr/local/bin takes precedence over /usr/bin on $PATH (so
  that the /usr/local/bin/firefox firejail symlink appears before
  /usr/bin/firefox).

Or:

• Setting $BROWSER to firejail firefox, firejail /usr/bin/firefox,
  ~/bin/firefox, or /usr/local/bin/firefox)

That can be probably be configured wherever fireurld is started, for example:

• ~/.xinit
• systemd/runit user service
• xdg-autostart
• Manually

There is also the issue of how a given program may try to determine what is
the default web browser (which may vary between different programs), and
how easy it would be to convince all applicable programs to use something
like fireurl, though this issue might warrant its own discussion.

Yes, that's a valid point. FWIW I've seen applications using:

• gio
• gvfs
• xdg

Each of these tools has commands to query/set the default handlers for
text/html and/or x-scheme-handler/http{,s}, so there's a few things we could
build on.

Yes, a given program may try any of the methods used in the implementation
examples or it may do whatever Qt/GTK/etc does by default or it may try to find
it out manually using custom logic.

Ideally the default browser would always be overridable through an env var, to
avoid having to create custom executables or trying to debug MIME.

That is, hopefully it would first try $BROWSER (or whatever environment
variable would be the most appropriate), then xdg-open, then whatever else.

I'm not sure what it would take to override it in every program, but as one
example I remember creating an x-www-browser file to try to prevent some
programs from opening Firefox when I didn't intend to and it worked at least
for the intended programs.