Consistency across ghidra application settings paths (portability)

[bukowa]

Is your feature request related to a problem? Please describe.

Ghidra is not consistent when it comes to application settings path. Lets take a look at application.settingsdir that you can declare in launch.properties file and application.version that you declare in application.properties.

ghidra/Ghidra/RuntimeScripts/Common/support/launch.properties

Lines 86 to 97 in 4247ae7

	# Settings directory used by the application to store application settings and data that persist
	# between application sessions, system reboots, and periodic system cleanup. Overridden values
	# are required to be absolute paths. The current user name may be incorporated into the settings
	# directory's name if the settings directory lives outside of the user's home directory. The
	# settings directory will be selected based on the following rules, in order of precedence:
	# 1. System.getProperty("application.settingsdir")/[user-]<application>/<application>_<version>
	# 2. System.getenv("XDG_CONFIG_HOME")/[user-]<application>/<application>_<version>
	# 3. A platform specific default location:
	# - Windows: %APPDATA%\<application>\<application>_<version>
	# - Linux: $HOME/.config/<application>/<application>_<version>
	# - macOS: $HOME/Library/<application>/<application>_<version>
	#VMARGS=-Dapplication.settingsdir=

ghidra/Ghidra/application.properties

Line 2 in 4247ae7

application.version=11.4

Given my username buk:

Example 1:

#VMARGS=-Dapplication.settingsdir=

C:\Users\buk\AppData\Roaming\AppData\ghidra_11.3_PUBLIC

Example 2:

VMARGS=-Dapplication.settingsdir=C:\ghidra\ghidra_11.3\Contrib\APPDATA

C:\ghidra\ghidra_11.3\Contrib\APPDATA\buk-ghidra\ghidra_11.3_PUBLIC

Result:

• ghidra creates subdirectories inside settingsdir path (hard to know what will be final path)
• ghidra creates directory based on application.version (setting that comes from totally different file which also requires changing when your trying to make the installation portable)
• ghidra doesn't allow relative paths in these settings (harder to make it portable)

Extra:

• this makes it very inconsistent and hard to make a portable installation.
• there is probably more issues related to these settings:
  • java 'binexport tried to access method' when non default settingsdir set in launch.properties ubfx/BinDiffHelper#34

Describe the solution you'd like
Consistent way that allows for portability.

[ryanmkurtz]

I don't really see any bugs here regarding inconsistency, but would something like VMARGS=-Dapplication.portable=true, where it puts the user settings/cache/temp directory inside the installation directory solve all of your problems?

[bukowa]

but would something like VMARGS=-Dapplication.portable=true, where it puts the user settings/cache/temp directory inside the installation directory solve all of your problems?

I hope so ^^

[ryanmkurtz]

What would get you to an "I know so?" I ask because I don't want to potentially implement something that won't actually address the problem you are having. You are just trying to prevent Ghidra from using any files outside of its installation directory, correct?

[bukowa]

What would get you to an "I know so?" I ask because I don't want to potentially implement something that won't actually address the problem you are having. You are just trying to prevent Ghidra from using any files outside of its installation directory, correct?

Oh right, I can't know ahead of time that everything is gonna work and that it will solve all my problems.

You are just trying to prevent Ghidra from using any files outside of its installation directory, correct?

Yes, portability. So in the end you can copy / paste ghidra directory anywhere and it should work just fine.
I think JAVA_HOME_OVERRIDE may be also important here.

[ryanmkurtz]

I think JAVA_HOME_OVERRIDE may be also important here.

We could potentially make that support relative paths from the root of the installation, but currently Ghidra requires at least Java 1.8 to be on the PATH or on JAVA_HOME, so Ghidra can run enough Java to find a supported JDK (21, currently).

[bukowa]

I think JAVA_HOME_OVERRIDE may be also important here.

We could potentially make that support relative paths from the root of the installation, but currently Ghidra requires at least Java 1.8 to be on the PATH or on JAVA_HOME, so Ghidra can run enough Java to find a supported JDK (21, currently).

Is this doable to rewrite? You mean these?

ghidra/Ghidra/RuntimeScripts/Linux/support/launch.sh

Lines 129 to 135 in a8f446f

	JAVA_CMD=
	if [ -x "$(command -v java)" ] ; then
	JAVA_CMD=java
	elif [ -n "${JAVA_HOME}" ] ; then
	JAVA_CMD="${JAVA_HOME}/bin/java"
	if [ ! -x "${JAVA_CMD}" ] ; then
	echo "WARNING: JAVA_HOME environment variable is set to an invalid directory: ${JAVA_HOME}"

ghidra/Ghidra/RuntimeScripts/Windows/support/launch.bat

Lines 116 to 122 in a8f446f

	set JAVA_CMD=java.exe
	java.exe -version >NUL 2>&1
	if %ERRORLEVEL% equ 0 goto continue3
	:: check for java based upon JAVA_HOME environment variable
	if not defined JAVA_HOME goto javaNotFound
	set "JAVA_CMD=%JAVA_HOME%\bin\java.exe"

[ryanmkurtz]

Yea, code would have to be added to those 2 files to parse the launch.properties file, get that override value, and use it. Definitely doable, but doing anything in a batch file is super annoying. That's why most of the logic is offloaded to the LaunchSupport java component.

[ryanmkurtz]

However, if instead of using that property, it instead just looked inside of say, <install_dir>/java, that would be super easy.

[bukowa]

However, if instead of using that property, it instead just looked inside of say, <install_dir>/java, that would be super easy.

Seems like a good solution to not touch any batch files :D

[bukowa]

I wonder if instead of <instrall_dir>/java they (all portable definitions like appdata,cachedata) could be place in a <install_dir>/portable instead ex.:

<install_dir>/portable/java
<install_dir>/portable/appdata
<install_dir>/portable/cachedata
<install_dir>/portable/projects

If Ghidra detects portable mode it could automatically default here to that directory (to save time)

[ryanmkurtz]

Yes, I think that's a good idea. I will bring this up to the team next week. It should be trivial to implement.