Chromium

[p1839251]

I was wondering what a 'supported web browser' is.
Did you mean Firefox?
I'd like to use Chromium. Should I just modify this line

firejail-handler-http/firejail-handler-settings-http.inc

Line 14 in bebd244

_browser_bin="/usr/bin/firefox"

to _browser_bin=/usr/bin/chromium and I'm ready to go?

There isn't much documentation of this issue.

[glitsj16]

I was wondering what a 'supported web browser' is.

Hi @p1839251. Your question made me realise this 'supported web browser' phrase is indeed not very clear. It needs to be a web browser with a working firejail profile. Either one that comes with the default firejail installation or one that a user put together manually. Hopefully this can clear up any confusion.

Should I just modify this line ... to _browser_bin=/usr/bin/chromium and I'm ready to go?

Correct. Because chromium is officially supported by firejail it fully qualifies to be used as your preferred web browser for handling http(s) links.

[p1839251]

Let's see;
I have modified the aforementioned file to _browser_bin=/usr/bin/chromium
I have configured Konversation to use this web browser firejail-handler-http "%u"
It won't work and firejail-handler-http is very shy and doesn't output anything in the terminal.

I don't know what else I should do!
(Chromium isn't firejailed by default here)

[glitsj16]

Apologies for responding so late. If you're still interested, there's a debug value you can flip in firejail-handler-settings-http.inc. That will output whatever data is received to ${HOME}/Downloads/firejail-xdg-open.log. If you could post that here we can look into what's happening exactly.

[p1839251]

firejail-handler-http was installed from the AUR.
firejail-handler-settings-http.inc file is currently looking like this: https://bpa.st/raw/FIEA
Konversation is set to use a custom webbrowser : firejail-handler-https "%u"(it has been tried with and without "%u")
I clicked on a link but nothing happened.
I checked the Downloads folder
$ ls ~/Downloads
but it remained empty!

[glitsj16]

In that case I'd try to join the konversation sandbox and run firejail-handler-http (no s) manually from inside the sandbox:

$ firejail-handler-http https://example.com

I do hope Konversation is actually using xdg-open in the first place, something I never actually researched (not having touched KDE ever). I'll try to found out.

[glitsj16]

I do hope Konversation is actually using xdg-open in the first place, something I never actually researched (not having touched KDE ever). I'll try to found out.

Hang on! I just had a look at /etc/firejail/konversation.profile. That has private-bin, so what happens when you add private-bin xdg-open to a konversation.local file? You can create one under ${HOME}/.config/firejail is you don't have one.

[p1839251]

firejail-handler-http (no s)

Thanks, fortunately it was just a typo here

I'd try to join the konversation sandbox and run firejail-handler-http manually from inside the sandbox

I'm not sure if you meant this:

firejail --profile=/etc/firejail/konversation.profile firejail-handler-http https://example.com
Error: no suitable firejail-handler-http executable found

Adding private-bin xdg-open to konversation.local didn't solve the problem
In fact, nothing really visible happened.

I tried running firejail-handler-http https://example.com outside the sandbox and nothing happened.
~/Downloads is still an empty folder

[glitsj16]

You will need to add your custom browser (chromium) AND every command used by firejail-handler-http and firejail-xdg-open to konversation's private-bin in a konversation.local.

$ cat ~/.config/firejail/konversation.local
# Firejail profile for konversation
# Persistent local customizations

# overrides for firejail-handler-http
include allow-bin-sh.inc
private-bin awk,basename,bash,chromium,dash,env,firejail-handler-http,firejail-xdg-open,grep,sed,sh,which

HTH

[p1839251]

I hope it'll work but I have this error message:
/usr/local/bin/firejail-handler-http: line 17: .: firejail-handler-settings-http.inc: file not found

https://github.com/glitsj16/firejail-handler-http/blob/master/firejail-handler-http#L17
(I'm using firejail-handler-http 0.1.0-5)

[glitsj16]

@p1839251 Thanks for reporting the error message. I definately will look into this, and I have some time to do just that. But I would appreciate some input, as the above error message (partly) puzzles me a bit. Let me elaborate.

/usr/local/bin/firejail-handler-http: line 17: .: firejail-handler-settings-http.inc: file not found

I'm not sure how exactly firejail-handler-http ended up in /usr/local/bin on your end. The AUR PKGBUILD installs it in /usr/bin as you can see here. Did you use an AUR-helper or makepkg'ed this yourself to install the files? Made any changes to the PKGBUILD?

It would also be helpful if you could tell me the command you ran that produced the error message. In the mean time I'll do some more digging to see where I can improve the scripts and solve this ASAP.

[p1839251]

Thank you for your quick response.
I don't use AUR helpers. I noticed you had updated the PKGBUILD a month ago, and I installed the new version of firejail-handler-http by running makepkg -sri.
I didn't make any changes to the PKGBUILD.
I did make changes when you asked me to turn debugging on when the configuration file was /usr/bin/firejail-handler-settings-http.inc, but the file is no longer available:

$ ls /usr/bin/firejail-handler-settings-http.inc
ls: cannot access '/usr/bin/firejail-handler-settings-http.inc': No such file or directory

I followed your instructions and they wouldn't work. I mean I still wasn't able to open links. Nothing happened.
So I went through all our conversation once again.

I ran the command I wrote here #2 (comment)

$ firejail --profile=/etc/firejail/konversation.profile firejail-handler-http https://example.com         
Reading profile /etc/firejail/konversation.profile
Reading profile /home/p1839251/.config/firejail/konversation.local
Reading profile /etc/firejail/allow-bin-sh.inc
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-shell.inc
Reading profile /etc/firejail/disable-xdg.inc
Reading profile /etc/firejail/whitelist-var-common.inc
Parent pid 4936, child pid 4937
13 programs installed in 32.14 ms
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Blacklist violations are logged to syslog
Child process initialized in 210.75 ms
/usr/local/bin/firejail-handler-http: line 17: .: firejail-handler-settings-http.inc: file not found

Parent is shutting down, bye...

[glitsj16]

I didn't make any changes to the PKGBUILD.

Good.

I did make changes when you asked me to turn debugging on when the configuration file was /usr/bin/firejail-handler-settings-http.inc, but the file is no longer available

Correct. The settings file now resides in /etc/firejail as per 7dbfd00 to fix #4.

Before we proceed to the testing part, let's double-check your file layout is exactly the same as in the PKGBUILD for 0.1.0-5:

/etc/firejail/firejail-handler-settings-http.inc
/etc/xdg/autostart/firejail-handler-http-ctl.desktop
/usr/bin/firejail-handler-http
/usr/bin/firejail-handler-http-ctl
/usr/local/bin/xdg-open (which needs to have the content of firejail-xdg-open from this repo obviously)

It's still unclear to me why you have a /usr/local/bin/firejail-handler-http. It might be a left-over from earlier attempts to get this working, IDK. In any case you'll need to remove that file from /usr/local/bin to ensure /usr/bin/firejail-handler-http has PATH precedence and is the only firejail-handler-http file on your system.

I ran the command I wrote here #2 (comment)
$ firejail --profile=/etc/firejail/konversation.profile firejail-handler-http https://example.com

That command sandboxes firejail-handler-http (a simple shell script) with the konversation profile. It's not what I meant by "I'd try to join the konversation sandbox and run firejail-handler-http manually from inside the sandbox". Let's try to clear up the confusion here. If you have the files from this repo installed to the correct locations and have a konversation.local to support them, it's easy to join the konversation sandbox after you've started konversation like you're used to. Firejail has a seperate --join command for doing so. It can refer to the sandbox via PID or via name, the latter being the easier of the two (it saves you the trouble of finding the PID of your running konversation sandbox in this context). You can add name konversation to your konversation.local. Talking of konversation.local, re-reading the thread I noticed making a mistake in #2 (comment). firejail-xdg-open gets installed as /usr/local/bin/xdg-open, so the private-bin line should reference xdg-open instead of firejail-xdg-open. Here's an updated and corrected example of what your konversation.local should look like:

$ cat ~/.config/firejail/konversation.local
# Firejail profile for konversation
# Persistent local customizations

# overrides for firejail-handler-http
include allow-bin-sh.inc
private-bin awk,basename,bash,chromium,dash,env,firejail-handler-http,grep,sed,sh,which,xdg-open
name konversation

After checking your file layout (as per above) and editing konversation.local, start your konversation app. Once that is running, join its sandbox by running:

$ firejail --join=konversation

You should get a bash prompt after issueing that command. On a side note, /etc/firejail/firejail.config has a setting to turn this into a green prompt, making it stand out from your regular shell prompts, so you'd be aware of being inside a firejail now (firejail-prompt yes). It's a nice extra to debug any sandbox, a tool to have an inside view of a running firejail sandbox so to speak. It is in this shell I wanted you to run firejail-handler-http https://example.com. Try this again please and report back what that does.

[glitsj16]

@p1839251 Shortly after adding the above comment, I decided to bump the AUR package to 0.1.1-1. So if you would like to test the above, try the newly released version please. Thanks for your continued attempts to get chromium working just as well as firefox with these scripts. However challenging it might (prove to) be, it is something I regard as very worthwhile.

Regards!

[p1839251]

I went through the files:

$ ls /etc/firejail/firejail-handler-settings-http.inc
/etc/firejail/firejail-handler-settings-http.inc

$ ls /etc/xdg/autostart/firejail-handler-http-ctl.desktop
/etc/xdg/autostart/firejail-handler-http-ctl.desktop

$ ls /usr/bin/firejail-handler-http
/usr/bin/firejail-handler-http*

$ ls /usr/bin/firejail-handler-http-ctl
/usr/bin/firejail-handler-http-ctl*

$ ls /usr/local/bin/xdg-open
/usr/local/bin/xdg-open*

I didn't/don't have /usr/local/bin/firejail-handler-http. I was trying to demonstrate it by:

$ ls /usr/local/bin/firejail-handler-http
ls: cannot access '/usr/local/bin/firejail-handler-http': No such file or directory

That was what the error message also said:
/usr/local/bin/firejail-handler-http: line 17: .: firejail-handler-settings-http.inc: file not found
But this error message may be irrelevant as I was running the wrong command.

I followed your instructions carefully and updated firejail-handler-http to 0.1.1-1
as well as konversation.local.

$ cat konversation.local
include allow-bin-sh.inc
private-bin awk,basename,bash,chromium,dash,env,firejail-handler-http,xdg-open,grep,sed,sh,which
name konversation

$ firejail --join=konversation
Switching to pid 6543, the first child process inside the sandbox
Child process initialized in 7.76 ms
bash: pulsemixer: command not found
bash: /usr/bin/df: No such file or directory
bash: tr: command not found
bash: tail: command not found
bash: [: : integer expression expected


$ firejail-handler-http https://example.com
which: no xdg-user-dir in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)

Thank you for your patience

[glitsj16]

I didn't/don't have /usr/local/bin/firejail-handler-http.

That's good, one less thing to focus on. Also, the rest of your output really helps, thanks for that. It gives me a better view on the whole context and what we need to try to get chromium working. Personally I've zero experience with KDE, but that shouldn't stop us here.

Thank you for your patience

Likewise :-). We'll get there, it's just a matter of putting together the correct private-bin without loosening the sandbox. I'll go over your output and will try to explain what's happening as straightforward as I can.

$ firejail --join=konversation
[...]
bash: pulsemixer: command not found
bash: /usr/bin/df: No such file or directory
bash: tr: command not found
bash: tail: command not found
bash: [: : integer expression expected

The above bash output is the result of having private-bin awk,basename,bash,chromium,dash,env,firejail-handler-http,grep,sed,sh,which,xdg-open in your konversation.local. You can see that pulsemixer, df, tr and tail are missing from that private-bin, and that's exactly why bash cannot find them. These are only needed for the --join command and we shouldn't add them in the final private-bin that we'll be putting together later on. You _can_make these errors go away simply by adding ignore private-bin to konversation.local instead of specifying a private-bin line. But doing so will loosen the profile, which isn't advised. In the mean time I think you've got the basic idea, and also noticed that the sandbox stays running as long as the (joined) shell stays open, even when you close konversation down by regular means. Just 'exit' the shell to return to normal behaviour.

$ firejail-handler-http https://example.com
which: no xdg-user-dir in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)

This one instead is very relevant indeed. The xdg-user-dir command is being used throughout the scripts from this package, so we need to add it to private-bin. I simply missed it before! But let's move on to the next attempt. Make sure the konversation sandbox(es) are shut down, edit your konversation.local as per below and try again :-)

$ cat ~/.config/firejail/konversation.local
# Firejail profile for konversation
# Persistent local customizations

# overrides for firejail-handler-http
include allow-bin-sh.inc
private-bin awk,basename,bash,chromium,dash,env,firejail-handler-http,grep,sed,sh,which,xdg-open,xdg-user-dir
name konversation

[p1839251]

It's still not working :/

$ cat ~/.config/firejail/konversation.local
include allow-bin-sh.inc
private-bin awk,basename,bash,chromium,dash,env,firejail-handler-http,xdg-open,xdg-user-dir,grep,sed,sh,which
name konversation

$ firejail --join=konversation
Switching to pid 2364, the first child process inside the sandbox
Child process initialized in 9.51 ms
bash: pulsemixer: command not found
bash: /usr/bin/df: No such file or directory
bash: tr: command not found
bash: tail: command not found
bash: [: : integer expression expected

$ firejail-handler-http https://example.com
which: no xdg-user-dir in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)

[glitsj16]

which: no xdg-user-dir in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)

I think your system is missing the xdg-user-dirs package (to which /usr/bin/xdg-user-dir belongs). That's my mistake, I should have added that to the PKGBUILD depends array. Sorry about that. I've updated the AUR package just now. You can do a quick test by installing that package, confirming you have /usr/bin/xdg-user-dir. Better re-login after ensuring xdg-user-dirs is installed.

[p1839251]

I think your system is missing the xdg-user-dirs package

That's kind of awkward. I did check it but I thought it was part of the xdg-utils package.
Anyway, I've updated your package and it says:

$ firejail-handler-http https://example.com
which: no DOWNLOAD in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)
/usr/local/bin/firejail-handler-http: line 50: /usr/local/bin/xdg-user-dir/.firejail-dropzone/firejail.drop: Not a directory

[glitsj16]

Needed to fix the error you saw so I cut a new release again (0.1.2-1). I do want to thank you for pursuing this. We're pretty close now I think. Apparently I had a very bad day coding in the user-defined settings support. Things should be quite a bit saner now.

[p1839251]

Ok, debugging isn't going to be that 'simple' anymore:

$ which chromium
/usr/bin/chromium

$ cat ~/.config/firejail/firejail-handler-settings-http.inc
#
# Shared settings for Firejail HTTP(S) URL handler scripts
#

# shellcheck disable=SC2034

### vars

#######################################
## IMPORTANT: use full paths in the variables below
#######################################

# web browser executable path
_browser_bin="/usr/bin/chromium"

# debug mode (enabled = 1; disabled = 0)
_debug=0

## dropzone location where the URL data will be saved temporarily
#+ IMPORTANT: this needs to be read/write accessible in the sandbox
# follow XDG specifications and fallback to hardcoded drop dir location
# https://github.com/glitsj16/firejail-handler-http/issues/3
if [ "$(which xdg-user-dir)" ]; then
    _drop_dir="$(xdg-user-dir DOWNLOAD)"
else
    _xdg_config_home="$(env | grep -c "XDG_CONFIG_HOME")"
    if [ "$_xdg_config_home" = 1 ]; then
        if [ -s "${XDG_CONFIG_HOME}/user-dirs.dirs" ]; then
            _drop_dir="$(grep "^XDG_DOWNLOAD_DIR=" "${XDG_CONFIG_HOME}/user-dirs.dirs" | awk '{split($0,a,"="); print a[2]}' | sed 's/"//g')"
        fi
    elif [ -s "${HOME}/.config/user-dirs.dirs" ]; then
        _drop_dir="$(grep "^XDG_DOWNLOAD_DIR=" "${HOME}/.config/user-dirs.dirs" | awk '{split($0,a,"="); print a[2]}' | sed 's/"//g')"
    else
        _drop_dir="${HOME}/Downloads"
    fi
fi
_drop_dir="${_drop_dir}/.firejail-dropzone"
_drop_file="${_drop_dir}/firejail.drop"

## xdg-open wrapper path
#+ IMPORTANT: this needs to point to a location preceding /usr/bin in your PATH
_xdg_open_wrapper_bin="/usr/local/bin/xdg-open"

$ firejail --join=konversation
Switching to pid 2477, the first child process inside the sandbox
Child process initialized in 8.70 ms
bash: pulsemixer: command not found
bash: /usr/bin/df: No such file or directory
bash: tr: command not found
bash: tail: command not found
bash: [: : integer expression expected
$ firejail-handler-http https://example.com

(The output hasn't been stripped. There's no output.)

[glitsj16]

Ok, debugging isn't going to be that 'simple' anymore

$ firejail-handler-http https://example.com
(The output hasn't been stripped. There's no output.)

That's expected behaviour. There is nothing to output, the URL simply gets written to ~/Downloads/.firejail-dropzone/firejail.drop temporarily. Once the inotifywait script (firejail-handler-http-ctl) observes that something has been written to that file it passes on the URL to /usr/local/bin/xdg-open and clears out the file, waiting for the next URL to arrive.

If you change _debug=0 to _debug=1 in your settings file /usr/local/bin/xdg-open will echo out the URL it received to ~/Downloads/xdg-open.log and exit. That's one way to check if the correct URL (in this case https://example.com) got passed to the script. Was your configured browser - chromium - running when you tested this?

[p1839251]

I tried enabling debug mode (_debug=1) but ~/Downloads remained empty.
I must have been doing something wrong - again.

Was your configured browser - chromium - running when you tested this?

Oh, I didn't know it had to be closed!
It was running, as I was following your instructions.
But firejail-handler-http has been working well since I closed chromium. Thank you so much!

A wiki or manual page should be created because it's not something I could have figured out all by myself.
I think the issue has been resolved and if you agree, this case can be closed now.

[glitsj16]

I tried enabling debug mode (_debug=1) but ~/Downloads remained empty.
I must have been doing something wrong - again.

Strange. It would be interesting to test this once more with the below settings file. If you still use the same settings file as you showed in #2 (comment) you should have ~/Downloads/.firejail-dropzone containing only one file called firejail-drop. If you use a GUI file-manager it might be needed to activate 'Show hidden files' (or similar wording) before you can see the subdir. I used a dotted subdir name on purpose here, to not clutter your ~/Downloads folder with dirs/files that are not very relevant when these scripts work as expected. But for testing you can also set the dir to a path of your choice. Please test with the below settings file:

#
# Shared settings for Firejail HTTP(S) URL handler scripts
#

# shellcheck disable=SC2034

### vars

#######################################
## IMPORTANT: use full paths in the variables below
#######################################

# web browser executable path
_browser_bin="/usr/bin/chromium"

# debug mode (enabled = 1; disabled = 0)
_debug=1

## dropzone location where the URL data will be saved temporarily
#+ IMPORTANT: this needs to be read/write accessible in the sandbox
# follow XDG specifications and fallback to hardcoded drop dir location
# https://github.com/glitsj16/firejail-handler-http/issues/3
_drop_dir="${HOME}/Downloads"
_drop_file="${_drop_dir}/firejail.drop"

## xdg-open wrapper path
#+ IMPORTANT: this needs to point to a location preceding /usr/bin in your PATH
_xdg_open_wrapper_bin="/usr/local/bin/xdg-open"

With the above you should see ~/Downloads/firejail-drop (_debug=0) or ~/Downloads/xdg-open.log (_debug=1), regardless of any GUI file manager settings. And you can always confirm these files exist via regular CLI commands like ls.

Was your configured browser - chromium - running when you tested this?
Oh, I didn't know it had to be closed!
It was running, as I was following your instructions.
But firejail-handler-http has been working well since I closed chromium. Thank you so much!

Although I'm happy to read you got things working, I'm not quite convinced this is the case. Your chromium should be running, and what's more important, it should be running firejailed! That's the whole point: to securely transfer a clicked URL out of your konversation sandbox to a temporary file that hands it over to your web browser of choice that's also sandboxed. It's very important you double-check this is actually the case on your side. Use firejail --tree to show all active sandboxes and confirm your chromium is in the output of that command. BTW, how do you start your firejailed chromium? Are you using the firecfg command or do you have a shell script for that perhaps?

A wiki or manual page should be created because it's not something I could have figured out all by myself.

I fully understand and agree. I'll be adding something soonish. And again, I really appreciate the trouble you have taken to improve the code. This all started out as a quick and dirty POC after dealing with an issue on Firejail's GitHub tracker. It's in a better state now thanks to your questions/posts.

[p1839251]

I'm using your config file:

[~/Downloads]$ rm -rf *
[~/Downloads]$ ls -a
./  ../
[~/Downloads]$ firejail --join=konversation 
Switching to pid 6857, the first child process inside the sandbox
Child process initialized in 9.97 ms
bash: pulsemixer: command not found
bash: /usr/bin/df: No such file or directory
bash: tr: command not found
bash: tail: command not found
bash: [: : integer expression expected
[~/Downloads]$ firejail-handler-http https://example.com
/usr/local/bin/firejail-handler-http: line 50: /home/p1839251/Downloads/.firejail-dropzone/firejail.drop: No such file or directory
[~/Downloads]$ 
exit
[~/Downloads]$ ls -a
./  ../

Hmm, this isn't really consistent. It worked yesterday.
I haven't done anything since yesterday.
I reverted the old configuration file, but it's still not working.

$ firejail --tree
7184:p1839251:konversation:/usr/bin/firejail /usr/bin/konversation -qwindowtitle Konversation
7186:p1839251::/usr/bin/firejail /usr/bin/konversation -qwindowtitle Konversation
7204:p1839251::/usr/bin/konversation -qwindowtitle Konversation

Chromium is not firejailed. #2 (comment)
It never was. I didn't mean to firejail that too.

Hmm, maybe I shouldn't have deleted my ~/Downloads folder. I thought it would be a good idea...
I created a dummy file:

$ mkdir .firejail-dropzone
$ cd .firejail-dropzone && touch firejail.drop

After running firejail-handler-http https://example.com in a sandbox, it didn't complain.

$ cat firejail.drop 
https://example.com

Chromium didn't open https://example.com though. I haven't tried closing Chromium yet, as I'm writing this message now.

UPDATE:
I've tried closing Chromium but it didn't solve the problem now :S

[glitsj16]

Hmm, maybe I shouldn't have deleted my ~/Downloads folder. I thought it would be a good idea...
I created a dummy file:

By emptying out your ~Downloads folder you broke the 'logic' these scripts share and things don't work anymore. The firejail-handler-http-ctl script creates the necessary subdir (.firejail-dropzone) and drop file (firejail.drop) in whatever dir you set as _drop_dir in the settings file (defaults to ~/Downloads).

Changing _debug=0 to _debug=1 makes /usr/local/bin/xdg-open echo out the URL and exit. In this debug mode the URL never reaches the configured web browser, so it's expected behaviour that your chromium didn't open the test URL (https://example.com). When you revert to your settings file (with _debug=0) you should log out and login to ensure all the scripts properly receive the same changes. I'm quite sure that things will start to work again once you do that.

Chromium is not firejailed. #2 (comment)
It never was. I didn't mean to firejail that too.

Although the scripts should also work with a non-firejailed web browser, that was never the intended use case. Obviously this is up to you, but personally I don't see the point of using firejail for konversation and not for any web browser. The attack surface of the latter is considerably larger IMO. It's also the reason why Firejail is called Firejail, as it was originally designed to sandbox Firefox. But again, things are up to you to decide here, firejail is just a tool.

[p1839251]

Ok, I'm lost.
What creates ~/Downloads/.firejail-dropzone/firejail.drop?
I thought I would start it all over and got rid of all the contents of ~/Downloads -again-.
I reinstalled firejail-handler-http and I just hoped it would work. (Downloads remained empty)

I may be alone with this but I don't really use the ~/Downloads folder and I even have a script that empties it periodically.
It probably means, it will break firejail-handler-http from time to time.

It would be great if firejail-handler-http just recreated the missing files and did not make it completely useless. It's not foolproof if I'd managed to mess it all up in no time.

I was a little bit misunderstood, I manually recreated the missing firejail.drop and reverted the whole old config file:
What I meant is:

$ cat .config/firejail/firejail-handler-settings-http.inc | grep debug
# debug mode (enabled = 1; disabled = 0)
_debug=0

Although firejail-handler-http https://example.com doesn't say /usr/local/bin/firejail-handler-http: line 50: /home/p1839251/Downloads/.firejail-dropzone/firejail.drop: No such file or directory anymore but nothing happens.

$ cat ~/Downloads/.firejail-dropzone/firejail.drop 
https://example.com

$ cat ~/.config/firejail/firejail-handler-settings-http.inc | grep browser
# web browser executable path
_browser_bin="/usr/bin/chromium"

My config file still looks like this: #2 (comment)

[glitsj16]

Ok, I'm lost.
What creates ~/Downloads/.firejail-dropzone/firejail.drop?

The firejail-handler-http-ctl script creates the necessary subdir (.firejail-dropzone) and drop file (firejail.drop) in whatever dir you set as _drop_dir in the settings file (defaults to ~/Downloads).

I may be alone with this but I don't really use the ~/Downloads folder and I even have a script that empties it periodically.
It probably means, it will break firejail-handler-http from time to time.

This is indeed a breakage point. The folder and file that needs to be watched by inotifywait for an incoming URL gets removed and the logic is broken from that moment on.

It would be great if firejail-handler-http just recreated the missing files and did not make it completely useless. It's not foolproof if I'd managed to mess it all up in no time.

Try to follow the logic of the scripts here. firejail-handler-http runs inside the sandbox and cannot recreate anything on the outside. This is by design and will not change because it would break the firejail sandbox, which is definately not something you'd want to happen.

If you cannot exclude ~/Downloads/.firejail-dropzone from your script that empties it I see only one other option: use another location for the _drop_dir than ${HOME}/Downloads. There's nothing stopping you from doing so, but there's a BIG catch: this location needs to be read-writable from inside the sandbox (cfr. https://github.com/glitsj16/firejail-handler-http/blob/master/firejail-handler-settings-http.inc#L20). I didn't go for ${HOME}/Downloads for fun or out of sheer coincidence, but because this location is special in Firejail, together with ${DESKTOP}. Most of the Firejail profiles will be able to access these dirs, which makes them perfect candidates for what these scripts try to achieve.

To repeat, these are the options you have AFAICT, from 'fairly easy' to 'tricky':

• exclude ${HOME}/Downloads/.firejail-dropzone in your script that cleans your ~/Downloads
• set _drop_dir to ${HOME}/Desktop in the settings file
• set _drop_dir to somewhere else under your ${HOME} and ensure that path is read-writable in Firejail

An example of the latter would be:

$ cat ~/.config/firejail/globals.local
# Firejail :: persistent global definitions

# blacklist the firejail-handler-http dropzone
# remember to noblacklist this path in the profiles you use those scripts from
# like konversation.local
blacklist ${HOME}/my_drop_dir_location

$ cat ~/.config/firejail/konversation.local
# Firejail profile for konversation
# Persistent local customizations

# overrides for firejail-handler-http
noblacklist ${HOME}/my_drop_dir_location
[...]

[p1839251]

Thanks once again!
I was just about to find a new location for firejail.drop but you convinced me it's more likely to break so I decided not to touch that.
I can't say I fully understand how it works but I realized .firejail-dropzone/firejail.drop got recreated upon restart.
It's probably saner to exclude this directory from my script so I'll do that.
It didn't work when I manually created it but after rebooting my system, it started working properly.
I'll let you know if something went wrong again!

[glitsj16]

I can't say I fully understand how it works but I realized .firejail-dropzone/firejail.drop got recreated upon restart.

It didn't work when I manually created it but after rebooting my system, it started working properly.

We touched on this above.

Ok, I'm lost.
What creates ~/Downloads/.firejail-dropzone/firejail.drop?

The firejail-handler-http-ctl script creates the necessary subdir (.firejail-dropzone) and drop file (firejail.drop) in whatever dir you set as _drop_dir in the settings file (defaults to ~/Downloads).
This script gets autostarted on each session login by firejail-handler-http-ctl.desktop (which is installed in /etc/xdg/autostart by the PKGBUILD. This is just the way the XDG specification works, and why a restart/relogin gets things going again for as long as your login session is active. Simply recreating .firejail-dropzone/firejail.drop manually is not enough, it needs the inotifywait command from firejail-handler-http-ctl to connect all the dots. I might be able to implement that as a systemd user service, which has the advantage of being able to restart on failure (without having to restart/relogin).

It's probably saner to exclude this directory from my script so I'll do that.

I think this is the best option indeed.

I'll let you know if something went wrong again!

Sure, feel free to add to this thread. All the best!