Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
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 '13 at 20:35
add comment

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer
Thanks, option 2 is the best for what I wanted, and all are very interesting. –  Neil Mitchell May 4 '13 at 6:30
add comment
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.

share|improve this answer
What is the 3<> syntax? What does it do? –  Neil Mitchell May 4 '13 at 6:31
@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). –  Hauke Laging May 4 '13 at 12:45
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.