The Hello World example shows echoing to stdout from the duress script. Seems like a bad idea. I don't want to get beaten or shot when some rm -rf fails with an I/O error, alerting the attacker to what's going on. It seems like it would be more sensible for the module to suppress all output by design.
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!
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.
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.
