Hey, saw this as mentioned earlier and incorporated your feedback and one other commenter that pointed out a privilege escalation vulnerability. If you have a spare moment would appreciate your critique on the resolution to your concern and/or any other issues you see generally with the codebase. Just a request though, regardless thanks for your feedback!

https://github.com/nuvious/pam-duress/pull/19

Just do this in your script

    rm -rf /secret/files > /dev/null 2>&1

That pipes STDOUT to /dev/null and redirects STDERR to STDOUT.

I may actually incorporate that into the system() call in the module itself now that I think about it. The Hello World implementation was just a quick way for me to debug while I developed it and it's probably smarter to dump it to /dev/null by default.

Seems like this should be baked in to the module. There don't seem to be any circumstances where you would want stdout/stderr from duress.d scripts to appear.

You have the freedom to do whatever you want with the script. It's trivial to `exec >/dev/null 2>/dev/null` first thing in a script if you want it to be silent.

Do you want to first find that out when you're under duress? Sensible defaults matter.

Are you seriously writing a script when the cops are at your door? No, you aren't. You always need to verify that your protective mechanisms work before actually relying on them.

As I alluded to in my original comment, you might not pick up on a transient error like an I/O error during testing. This is exactly the sort of thing a sensible default setting in the program should cover.

I'm sorry but error handling and testing requirements are true for any software or script a person writes. The application should not give a shit, and a simple execve() is the best way to go about it. It's the principle of least surprise, and people have had to keep in mind fork/exec semantics for decades.