They hang around after you need them. Environment gets leaked in all kinds of debugging and logging. Other processes can read them even with restricted ptrace. Just say no.
Edit: add alt
@rk We Should Have Listened
On POSIX, put your secrets in a directory as individual files, unwriteable, remove the directory entry from its parent directory, pass the secret dirfd to your subprocess so it can do openat(2) and everyone’s happy. You could even pass the secret dirfd via UNIX domain sockets if you wanted.
(This is probably over engineered but I like it.)
(Someone prolly already does this but I’m too lazy to check.)
@rk @sj Except rmdir(2)
is going to fail with ENOTEMPTY
, no? You can hold an open fd for an empty directory, but then creating a new file inside it via openat
on the directory fd still fails with ENOENT
(and similarly if you hold on to it by chdir
-ing into it instead of opening it and then creating things in ".").
You could also put secrets in anonyous tempfiles, but at least on Linux other processes could still access it via /proc/$PID/fd
.