Open ipaqmaster opened 7 months ago
Creating /etc/firejail/hashcat.local
with content ignore private-tmp
resolves the access issue.
Despite no other hashcat
process on the system yet re-launching it also sometimes throws Already an instance '/usr/bin/hashcat' running on pid 7
despite there being no other hashcat processes running. But only sometimes.
Late December I enabled firejail system-wide with sudo firecfg and have since had to rm many of its /usr/local/bin/ symlinks to get programs to work.
Just a FYI: upcoming Firejail release will support improved firecfg disablements via /etc/firejail/firecfg.d. Please report profile bugs for programs that you observe to not work as expected with firecfg.
Creating /etc/firejail/hashcat.local with content ignore private-tmp resolves the access issue.
Can you open a PR to fix hashcat.profile accordingly?
Description
Describe the bug
Late December I enabled firejail system-wide with
sudo firecfg
and have since had torm
many of its/usr/local/bin/
symlinks to get programs to work. Today I experienced Hashcat not recognizing hash files and being entirely unusable as a result. It was even unable to recognize example hashes it had generated itself which is how I realized this isn't just a bad library or partially updated package situation but rather firejail having a profile for it. After removing/usr/local/bin/hashcat
it resumed functioning as expected.In this case the intended hash is sitting in a /tmp tmpfs as /tmp/file.txt
Steps to Reproduce
Steps to reproduce the behavior
No hash-mode matches the structure of the input hash.
despite definite support for the hashes contained within the file.Expected behavior
What you expected to happen
Hashcat to prepare the graphics card for enumerating the hash as is normal operation and then beginning that task.
Actual behavior
What actually happened
Hashcat cannot identify hashes. More realistically it likely just cannot read the file. The same thing happens when I call
hashcat /dev/null
which simulates an unreadable content source and also throwsNo hash-mode matches the structure of the input hash.
just like it does with firejail.Behavior without a profile
_What changed calling
LC_ALL=C firejail --noprofile /path/to/program
in a terminal?_It seems to work fine and detects the hash. Both with and without LC_ALL=C however I am aware this issue seems to just require a
hashcat.profile
tweak.Additional context
Any other detail that may help to understand/debug the problem
Oddly if I call
firejail hashcat /the/hash/file.txt
it throws a different error/usr/local/bin/OpenCL/: No such file or directory
, this is inconsistent with the hashcat>firejail symlink which firecfg creates. I am not sure why invoking firejail for hashcat intentionally seems to exhibit a different problem than firecfg's firejail symlink for the application.The above quirk doesn't happen when specifying its full path /usr/bin/hashcat. Maybe just inheriting the terminal's profile when specified by shortname? Not relevant to the reported issue however.
Environment
Archlinux
firejail --version
).firejail version 0.9.72
git rev-parse HEAD
).Checklist
/usr/bin/vlc
) "fixes" it).https://github.com/netblue30/firejail/issues/1139
)browser-allow-drm yes
/browser-disable-u2f no
infirejail.config
to allow DRM/U2F in browsers.--profile=PROFILENAME
to set the right profile. (Only relevant for AppImages)Log
Output of
q
``` output goes here ```
Output of
LC_ALL=C firejail --debug /path/to/program
``` output goes here ```