research: delete 'other' files

[web.git] / personal / _posts / 2024-04-14-bubblebox.md

diff --git a/personal/_posts/2024-04-14-bubblebox.md b/personal/_posts/2024-04-14-bubblebox.md
index 85dc684ebdcdbb6fb5d7b658e92ae7cf35eff037..56a23a66937e751491a5e1fd1cc46cf8d611d048 100644 (file)
--- a/personal/_posts/2024-04-14-bubblebox.md
+++ b/personal/_posts/2024-04-14-bubblebox.md
@@ -33,12 +33,16 @@ org.freedesktop.Flatpak=none
 org.freedesktop.secrets=none
 ```
 
+I also use [Flatseal], an amazing application that helps to check which permissions applications get, and change them if necessary.
+
+[Flatseal]: https://flathub.org/apps/com.github.tchx84.Flatseal
+
 ## BubbleBox
 
 However, not all software exists as Flatpak.
 Also, sometimes I want software to run basically on my host system (i.e., to use the regular `/usr`), just without access to literally *everything* in my home directory.
 Examples of this are Factorio and VSCodium.
-The latter doesn't work in Flatpak as I want to use it with LaTeX, and realistically this means it needs to run the LaTeX on my host.
+The latter doesn't work in Flatpak as I want to use it with LaTeX, and realistically this means it needs to run the LaTeX installed via `apt`.
 The official recommendation is to effectively disable the Flatpak sandbox, but that entirely defeats the point, so I went looking for alternatives.
 
 [bubblewrap] provides a very convenient solution: it can start an application in its own private filesystem namespace with full control over which part of the host file system is accessible from inside the sandbox.
@@ -46,15 +50,18 @@ I wrote a small wrapper around bubblewrap to make this configuration a bit more
 this project is called [BubbleBox].
 This week-end I finally got around to adding support for [xdg-dbus-proxy] so that sandboxed applications can now access particular D-Bus functions without having access to the entire bus (which is in general not safe to expose to a sandboxed application).
 That means it's finally time to blog about this project, so here we go -- if you are interested, check out [BubbleBox];
-the project page explains how you can use it to set up your own sandboxing.
-One day I should probably rewrite this in Rust...
+the project page explains how you can use it to set up your own sandboxing.[^1]
+
+[^1]: One day I should probably rewrite this in Rust... maybe this will be my test project for when [cargo-script](https://rust-lang.github.io/rfcs/3424-cargo-script.html) becomes available.
 
 I should also note that this is not the only bubblewrap-based sandboxing solution.
 [bubblejail] is fairly similar but provides a configuration GUI and a good set of default provides;
 it was a very useful resource when figuring out the right bubblewrap flags to make complex GUI applications work properly.
 (Incidentally, "bubblejail" is also how I called my own script originally, but then I realized that the name is already taken.)
 Joachim Breitner also recently [blogged](https://www.joachim-breitner.de/blog/812-Convenient_sandboxed_development_environment) about his own bubblewrap-based sandboxing script.
-There are many ways to do this, and it was fun to figure out my own solution.
+sloonz has a similar [script](https://gist.github.com/sloonz/4b7f5f575a96b6fe338534dbc2480a5d) as well, with a nice yaml-based configuration format and [great explanations](https://sloonz.github.io/posts/sandboxing-1/) for what all the flags exactly do.
+Had their script existed when I started what eventually became BubbleBox, I would have used it as a starting point.
+But it was also fun to figure out my own solution.
 
 Using bubblewrap and xdg-dbus-proxy for this was an absolute joy.
 Both of these components came out of the Flatpak project, but the authors realized that they could be independently useful,