Add use_sudo config option for non-root Ghidra server management

[ANogin]

• I have reviewed the OFRAK contributor guide and attest that this pull request is in accordance with it.
• I have made or updated a changelog entry for the changes in this pull request.

One sentence summary of this PR (This should go in the CHANGELOG!)

Add use_sudo config option for non-root Ghidra server management

Link to Related Issue(s)

N/A

Please describe the changes in your request.

Allow non-root users to manage the Ghidra server by optionally prefixing server start/stop commands with sudo -n. Also switch from subprocess.call to subprocess.run(check=True) for starting/stopping ghidra so that failures are raised as errors.

Anyone you think should look at this, specifically?

@whyitfor ?

[whyitfor]

@claude, can you do some research on this PR. Is this change needed? Does the Ghidra server actually require sudo to run? Trying to understand if there is a simpler way to address this. Take your time, make no mistakes ;)

[claude]

Claude finished @whyitfor's task in 2m 36s —— View job

---

Research: Does the Ghidra Server Require sudo?

Tasks:

• Gather context from PR
• Read the current Ghidra server implementation
• Read the config files and changes
• Research Ghidra server requirements and svrInstall behavior
• Analyze if sudo is actually needed
• Evaluate alternatives
• Post findings

---

Short Answer

Yes, root privileges are genuinely required for the current OFRAK Ghidra server management approach. The use_sudo option is a legitimate and well-implemented solution.

---

Why Root Is Required

The root cause is in run_ghidra_server.sh, which OFRAK uses to start Ghidra:

# Line 13 of run_ghidra_server.sh
./server/svrInstall

svrInstall is Ghidra's script that installs the Ghidra server as a system daemon using YAJSW (Yet Another Java Service Wrapper). This requires root because it writes to system directories. The server.conf that OFRAK ships confirms this explicitly:

# server.conf, line 239
wrapper.daemon.run_level_dir=/etc/rcX.d

It installs init.d scripts and creates symlinks in /etc/rc*.d/ — paths that require root. Stopping the server (ghidraSvr stop) then controls this system service, also requiring elevated privileges.

The existing shell script even has a comment anticipating the sudo use case (line 32 of run_ghidra_server.sh):

# Also add root for when running with sudo, to make sure the repository can be created
./server/svrAdmin -add root

This was already present before this PR, confirming the use case was always intended.

---

Is There a Simpler Alternative?

There are a few approaches, but none simpler without meaningful trade-offs:

Approach	Root needed?	Effort	Trade-offs
use_sudo (this PR)	No (user needs passwordless sudo)	Low	Requires sudoers config
Docker (already supported)	No (runs as root in container)	None	Already works — recommended path
ghidraSvr console mode	No	Medium	Runs Java in foreground; would need to restructure server lifecycle management
pyghidra (partially in Dockerstub)	No	High	Embeds Ghidra in Python process — eliminates the server entirely, but big refactor

The Docker path is already the documented recommended approach for most users and avoids this entire issue. The use_sudo option makes sense specifically for native/non-Docker setups where users don't want to run their OFRAK process as root.

---

PR Quality Assessment

The implementation is clean and minimal. Some observations:

Improvements over the old code:

• The switch from subprocess.call to subprocess.run(check=True) (__main__.py:36) is an unconditional improvement — the old code silently ignored failures
• The sudo -n flag is correct: it's non-interactive (fails rather than prompting for password), which is the right behavior for programmatic use

Config handling:

• use_sudo: false default preserves backward compatibility with existing configs
• The isinstance(_use_sudo, bool) type check (ofrak_ghidra_config.py:68-72) prevents silent misconfiguration (e.g., if someone accidentally writes use_sudo: yes as a string instead of true as a boolean)

Minor observation: The use_sudo field is always serialized in to_yaml() — this means importing an old config file without use_sudo still works (it defaults to False via .get("use_sudo", False)) but a freshly exported config will always include the field. This is acceptable behavior.

Test coverage:

• Test skip condition os.geteuid() != 0 and not conf.use_sudo (test_ghidra_server.py:16) correctly gates tests to root or sudo-enabled environments

---

Verdict

The change is needed and well-implemented for the native (non-Docker) use case. The use_sudo: false default means no behavior change for existing users. If the team prefers to avoid this complexity, the guidance could instead emphasize Docker as the recommended path — but that doesn't help users who have legitimate reasons to run natively as non-root.