Open ANogin opened 1 year ago
Interesting. I've never run into this issue. What steps did you take to create this situation where you did not have permission for /tmp/ofrak.log
?
Interesting. I've never run into this issue. What steps did you take to create this situation where you did not have permission for
/tmp/ofrak.log
?
Invoked the default docker setup of having ofrak run the ghidra server as root, then tried docker exec -u aleksey ofrak-ghidra bash -l
as I did not want the wrong ownership on the files mounted from host, and ran ofrak there.
But I would imagine multiple users running pip install
ed ofrak on a shared server would result in the same issue.
If seems like we might want to:
What is the problem? (Here is where you provide a complete Traceback.)
We probably should not assume we can have exclusive use of
/tmp/ofrak.log
. It may be somewhat safe in a controlled docker environment where there is likely at most one instance of OFRAK running at a time, but not withpip install
, or whatever weird things people might choose to do, resulting in:Please provide some information about your environment. At minimum we would like the following information on your platform and Python environment:
redballoonsecurity/ofrak/ghidra
master
branch.If you've discovered it, what is the root cause of the problem?
DEFAULT_OFRAK_LOG_FILE = os.path.join(tempfile.gettempdir(), "ofrak.log")
inofrak_core/ofrak/ofrak_context.py
seems to be hardcoded (as far as I can tell, theDEFAULT_
part is misleading).How often does the issue happen?
What are the steps to reproduce the issue?
How would you implement this fix?
Are there any (reasonable) alternative approaches?
Are you interested in implementing it yourself?