I am publishing an unofficial snap of software reverse engineering tool Ghidra (upstream: https://ghidra-sre.org). Ghidra is a suite of tools for disassembling, de-compiling and debugging binaries.
I was expecting to maybe have to request classic confinement given the type of operations ghidra performs, however it seems to usable with just access to $HOME/.ghidra and $HOME/.cache.
.ghidra is used to store user preferences (which may already exist for existing non-snap users).
.cache appears (thanks to snappy-debug) to be used by the application for writing some temporary java native access files (JNA is a dependency of ghidras).
I would like to request access to the super-privileged interface personal-files, and also auto-connection of them.
Can you provide some more details? In particular, the names of the personal-files plugs that you are requesting, and the permission (read or write (which implies read))?
Of course. I’ve followed the naming convention dot-ghidra and dot-cache-jna so that it’s clear what directories those plugs refer to, and I’m requesting write access to both.
In the case of .ghidra write access is to both read and write preferences.
For .cache, the JNA library writes some temporary elf files there, so I have further restricted access to the directory .cache/JNA as below:
This will instruct the JVM to treat home as the typical fake $HOME, which will also have the benefit of putting the configuration files in a versioned location where they can be rolled back gracefully, cleaned automatically on un-installation, etc. The downside then of course is you wouldn’t pull existing configuration in the normal folders without manual import logic (which would still require the interfaces). I’m not a reviewer so I’ve no actual sway in things. But thought you might appreciate the input.
As far as I recall with Java/Swing, setting home in this manner doesn’t impact the file open/save interfaces, which determine $HOME via other means.
It is a nice suggestion, and I will try it locally to see how it works. Presuming it works, I might still prefer to use the users real home for the case of accessing existing configuration. Will give it a go, and some thought. Thanks.
It would be good if _JAVA_OPTIONS: -Duser.home="$SNAP_USER_DATA" works for the $HOME/.cache/JNA bits - as ideally that would not be needed. Whether it then also automatically translates $HOME/.ghidra to be within $SNAP_USER_DATA would be interesting to know too.
Tested, works well. I will use $SNAP_USER_DATA. Existing user configuration from non-snap installs wont be accessible, but users can remedy that quite easily by copying their .ghidra directory into the snap if desired.
I’ll cancel the manual review request and upload a version without the privileged interface plugs.
