gemini.git

going-flying.com gemini git repository

summary

tree

log

refs

ef752acba3bb43592d0554ad98287d5c8f1cdef2 - Matthew Ernisse - 1716915492

new post

view tree

view raw

diff --git a/users/mernisse/articles/34.gmi b/users/mernisse/articles/34.gmi
new file mode 100644
index 0000000..857f707
--- /dev/null
+++ b/users/mernisse/articles/34.gmi
@@ -0,0 +1,66 @@
+---
+Title: Overcoming a Missing Molly Brown Feature
+Date: 05/28/2024 13:00
+
+## Background
+Rather quickly after I setup a Gemini capsule I settled on Solderpunk's
+The Unsinkable Molly Brown as server software.  I created a Docker container
+as I'm not a fan of running untrusted code on my publicly accessible
+server infrastructure.  The container mounts /var/gemini, and the TLS
+certificate and key file read-only which restricts its ability to be
+harmful in the event it is ever compromised.  Until recently the
+/var/gemini directory contained just a checked out copy of a private(ish)
+git repository containing all the files served and all was well.
+
+At some point libgit2 got upgraded and the ancient CGI script that I have
+serving the git repository broke because it refuses to open a repository
+that isn't owned by the process owner.  My git hooks run as the git user
+but the container runs as a different UID which means that the checked-out
+copy of the repository isn't owned by the CGI script's EUID, causing it to
+fail.
+
+=> /git/cgi/gemini.git/summary	git repository browser
+
+I ended up fixing the permissions problem but in doing so I had to figure
+out how to keep the checked out copy in sync and the best way was to add
+the check out to the post commit hook.  This means that there is now git
+metadata files stored in the /var/gemini directory that someone could read.
+
+=> /files/deploy	deploy hook
+
+Obviously this is unacceptable and this is where the missing feature
+cropped up.  There appears to be no ACLs in Molly Brown's configuration.
+You can control if the directory is list-able but you cannot actually
+control if Molly Brown will serve requests from within that directory.
+
+=> https://tildegit.org/solderpunk/molly-brown	Molly Brown's source code
+
+The only reasonable way seems to be to create a PermRedirect and send
+the client somewhere acceptable.  In the case of my git repository
+this is reasonable, an invalid path will kick you back to the root of
+the CGI, however I'd much rather be able to tell Molly Brown to return
+a 5x error code to the client instead.
+
+In case someone needs it, below is an example.  Note that if you don't
+specify the capture group ( "(.*)$" ) in the match portion, it will do
+a simple replace, so given a configuration of:
+
+```
+[PermRedirects]
+"^/bad/request/" = "/error/notallowed.gmi"
+```
+
+A request for "/bad/request/file" would rewrite to "/error/notallowed.gmifile".
+
+So, to rewrite all requests under "/bad/requests" you would do something like
+the following.
+
+```
+[PermRedirects]
+"^/bad/request(.*)$" = "/error/notallowed.gmi"
+```
+
+The capture group should ensure the entire remainder of the request path is
+discarded.  Note that if you can access the value of the capture group using
+$1...$n variables in the substitution.
+