I want to create a file that is only accessible to the process that created it (and potentially its children), and that disappears when the process exits, ideally never persisting the file to disk. As an example, I want to create /mylocation/myfile.txt, where that file can only be read from the current process, but not any other processes, even from the same user. I am happy to use some magic location other than /mylocation, e.g. somewhere under /prod/PID, but it needs to work for any filename.

The background is that I am using an existing library which reads a password from $FOO/mypassword. Several processes are running under the same user account, but have different secret passwords. I wish to communicate the password to the library securely from the other processes. I appreciate the ideal solutions would user different user accounts or have the library not read the password from a file, but I do not have control over either of those aspects.

  • Given how the permissions in the Unix filesystem work I don't see how this will be possible. Access Control Lists (ACLs) may give you this capability, but I'm not sure.
    – slm
    May 2, 2013 at 20:35

2 Answers 2


Well, it depends on what you mean by "file" and how exactly the library accesses it. Here are a few approaches (both kluges) that come to mind:

  1. Use a temporary file, in the normal mkstemp meaning. mkstemp returns a file descriptor number to an unlinked file. You can then create $FOO/mypasswd as a symlink to /proc/self/fd/returned_number. There is a small window where the file exists (between open and unlink), and something else running as the same user could open it, and hold the file descriptor to later read the password. You can be sure it'll not be written to disk if your temporary directory is on a tmpfs.
  2. If it doesn't need to seek the password file, use pipe/pipe2 to create your file descriptors, then proceed as above with the symlink. You'll need to fork a child process to handle feeding the password to the pipe.
  3. You can probably abuse FUSE to do this.
  4. You could use LD_PRELOAD (or other dynamic linker tricks) to "fix" the library by intercepting the open/read/close, and feed it the password from somewhere sane.

None of these are really secure from other processes. Other processes running as the same user could, for example, ptrace your process and read the password directly out of memory.

  • Thanks, option 2 is the best for what I wanted, and all are very interesting. May 4, 2013 at 6:30
  • Linux 3.11 added O_TMPFILE flag that removes the window between create–unlink. May 7, 2019 at 11:19
exec 3<>file
rm file
exec program

To be precise: There is a race condition. And the program has to use the file descriptor. If you have to pass a file path then use /proc/self/fd/3. But theoretically the file (even though deleted) is accessible through this proc path for other processes, too.

  • What is the 3<> syntax? What does it do? May 4, 2013 at 6:31
  • 1
    @NeilMitchell > opens a file for writing, < for reading, and <> for reading and writing. This makes a connection from FD 3 to a certain inode even there is no file entry in any directory for it (assumed there was no second hardlink before the rm). When the process exits the FD is closed and the inode's reference count is decreased to zero, effectively deleting the file (releasing the allocated blocks). May 4, 2013 at 12:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .