Ok this one is a bit tricky:
GTK by default initiates a connection to dbus which cannot be disabled. However, GTK devs mentioned that it is not an issue to prevent the connection, either by blocking it (like flatpak does) or when there is no dbus session available. https://gitlab.gnome.org/GNOME/gtk/-/issues/4842
As far as I can see, zathura does not use any of the functionality provided by the native GTK dbus interface.
Why would we block it?
Basically to allow an effective sandbox isolation. Currently, we have a file descriptor to dbus open before the seccomp filter can do anything about it and that means that anyone gaining code execution, even in strict sandbox mode, can use said file descriptor for sandbox escape through dbus. The only way to prevent this is to block the connection when gtk_init() is run, which is currently also before the configuration file is read.
I know this looks like a dirty hack at first glance and I'm not really convinced myself about this solution but since GTK does not provide any other option to disable this but also allows blocking the connection attempt, this isn't completely crazy (I hope...) So far I have not noticed any regressions and unless someone find any, this could work.
If necessary, this change could be made dependent on the sandbox mode, however: Since the configuration is read after gtk_init, this would require a rewrite of init_zathura or the sandbox options would need to be changed into a command line argument. Before that I would like some feedback on this approach in general.
The seccomp filter in zathura has become quite mature in my opinion and this dbus socket is the last issue I know of that makes this incomplete (when run on wayland), which is why I would like to solve it.