Misp: gpg: agent_genkey failed: Permission denied
Hello, I've been trying to fix this error for many days, but there is no any solutions that work.
If anybody can solve this, please share your solutions.
Thank you.
If you would like to report a bug, please fill the template bellow
Work environment
| Questions | Answers
|---------------------------|--------------------
| Type of issue | Bug, Question, Feature Request, support...
| OS version (server) | Debian, ubuntu, CentOS, RedHat, ...
| OS version (client) | XP, Seven, 10, Ubuntu, ...
| PHP version | 5.4, 5.5, 5.6, 7.0, 7.1...
| MISP version / git hash | 2.4.XX, hash of the commit
| Browser | If applicable
Expected behavior
Actual behavior
Steps to reproduce the behavior
Logs, screenshots, configuration dump, ...
zero3228
All 5 comments
Maybe you want to set the tty ownership as described there: https://github.com/MISP/MISP/issues/2372#issuecomment-358790301
adulau
on 21 Sep 2018
zero3228
on 1 Oct 2018
Expected behavior. Here's why.
At the point of failure, gen-key is about to ask the user for a passphrase. For security purposes, rather than using stdin/stdout, it wants to directly open the controlling terminal for the session and use that handle to write the prompt and receive the passphrase. When you use su to switch to some other user, the owner of the controlling terminal device file _does not change_; it remains associated with the user who actually logged in (i.e. received a real terminal from getty or got a pty from telnet or ssh or whatever). That device file is protected mode 600, so it can't be opened by anyone else.
The solution is to sudo-chown the device file to the user-who-needs-to-gen-the-key _before_ su'ing to that user. Create the key within the su'd environment, then exit back to the original environment. Then, finally, sudo-chown the terminal back to yourself.
jasonzio
on 1 Dec 2018
@5730325021-PT closing this issue, I assume it is solved.
If not feel free to check out gitter
SteveClement
on 7 Jan 2019
So, service accounts that need to store passwords can't use the password manager because they can't set it up without sudo. Got it. This is a dumb security feature.
Maybe more helpfully, running tmux allowed this to succeed.
joncard1
on 21 Sep 2020
Related issues
RichieB2B
路
7Comments
Rafiot
路
3Comments
yannw
路
5Comments
bhuvan2099
路
7Comments
WakandaKing
路
5Comments
Most helpful comment
Expected behavior. Here's why.
At the point of failure, gen-key is about to ask the user for a passphrase. For security purposes, rather than using stdin/stdout, it wants to directly open the controlling terminal for the session and use that handle to write the prompt and receive the passphrase. When you use su to switch to some other user, the owner of the controlling terminal device file _does not change_; it remains associated with the user who actually logged in (i.e. received a real terminal from getty or got a pty from telnet or ssh or whatever). That device file is protected mode 600, so it can't be opened by anyone else.
The solution is to sudo-chown the device file to the user-who-needs-to-gen-the-key _before_ su'ing to that user. Create the key within the su'd environment, then exit back to the original environment. Then, finally, sudo-chown the terminal back to yourself.