github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #6148] hashcat: cannot recognise any hashes (even its own generated with `-m xxx --example-hashes`) when run against a hash file #3202

New issue

Open

opened 2026-05-05 09:49:14 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 09:49:14 -06:00

Owner

Originally created by @ipaqmaster on GitHub (Jan 2, 2024).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6148

Description

Describe the bug

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. 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

Run hashcat through firejail via the symlinks firecfg creates.
See error 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 throws No 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

Linux distribution and version (e.g. "Ubuntu 20.04" or "Arch Linux")

Archlinux

Firejail version (firejail --version).

firejail version 0.9.72

If you use a development version of firejail, also the commit from which it
was compiled (git rev-parse HEAD).

Checklist

The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
I can reproduce the issue without custom modifications (e.g. globals.local).
The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
The profile (and redirect profile if exists) hasn't already been fixed upstream.
I have performed a short search for similar issues (to avoid opening a duplicate).
- I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
I used --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

Originally created by @ipaqmaster on GitHub (Jan 2, 2024). Original GitHub issue: https://github.com/netblue30/firejail/issues/6148  ### Description _Describe the bug_ 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. 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_ 1. Run hashcat through firejail via the symlinks firecfg creates. 2. See error `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 throws `No 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 - Linux distribution and version (e.g. "Ubuntu 20.04" or "Arch Linux") Archlinux - Firejail version (`firejail --version`). firejail version 0.9.72 - If you use a development version of firejail, also the commit from which it was compiled (`git rev-parse HEAD`). ### Checklist  - [x] The issues is caused by firejail (i.e. running the program by path (e.g. `/usr/bin/vlc`) "fixes" it). - [x] I can reproduce the issue without custom modifications (e.g. globals.local). - [x] The program has a profile. (If not, request one in `https://github.com/netblue30/firejail/issues/1139`) - [x] The profile (and redirect profile if exists) hasn't already been fixed [upstream](https://github.com/netblue30/firejail/tree/master/etc). - [x] I have performed a short search for similar issues (to avoid opening a duplicate). - [ ] I'm aware of `browser-allow-drm yes`/`browser-disable-u2f no` in `firejail.config` to allow DRM/U2F in browsers. - [ ] I used `--profile=PROFILENAME` to set the right profile. (Only relevant for AppImages) ### Log <details> <summary>Output of <code>q</code></summary> <p> ``` output goes here ``` </p> </details> <details> <summary>Output of <code>LC_ALL=C firejail --debug /path/to/program</code></summary> <p>  ``` output goes here ``` </p> </details>

gitea-mirror added the

bug

label 2026-05-05 09:49:14 -06:00

gitea-mirror commented

2026-05-05 09:49:16 -06:00

Author

Owner

@ipaqmaster commented on GitHub (Jan 2, 2024):

Creating /etc/firejail/hashcat.local with content ignore private-tmp resolves the access issue.

@ipaqmaster commented on GitHub (Jan 2, 2024): Creating `/etc/firejail/hashcat.local` with content `ignore private-tmp` resolves the access issue.

gitea-mirror commented

2026-05-05 09:49:16 -06:00

Author

Owner

@ipaqmaster commented on GitHub (Jan 3, 2024):

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.

@ipaqmaster commented on GitHub (Jan 3, 2024): 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.

gitea-mirror commented

2026-05-05 09:49:17 -06:00

Author

Owner

@ghost commented on GitHub (Jan 3, 2024):

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?

@ghost commented on GitHub (Jan 3, 2024): > 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?

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#3202

No description provided.

Rows
Columns

[GH-ISSUE #6148] hashcat: cannot recognise any hashes (even its own generated with -m xxx --example-hashes) when run against a hash file #3202

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

Additional context

Environment

Checklist

Log

[GH-ISSUE #6148] hashcat: cannot recognise any hashes (even its own generated with `-m xxx --example-hashes`) when run against a hash file #3202