Single process accessible temporary file

filesprocesstmp

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.

Best Answer

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:

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.
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.
You can probably abuse FUSE to do this.
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.

Related Solutions

Process descendants

If you send a signal to a process, that process gets killed. I wonder how the rumor that killing a process also kills other processes got started, it seems particularly counter-intuitive.

There are, however, ways to kill more than one process. But you won't be sending a signal to one process. You can kill a whole process group by sending a signal to -1234 where 1234 is the PGID (process group ID), which is the PID of the process group leader. When you run a pipeline, the whole pipeline starts out as a process group (the applications may change this by calling setpgid or setpgrp).

When you start processes in the background (foo &), they are in their own process group. Process groups are used to manage access to the terminal; normally only the foreground process group has access to the terminal. The background jobs remain in the same session, but there's no facility to kill a whole session or even to enumerate the process groups or processes in a session, so that doesn't help much.

When you close a terminal, the kernel sends the signal SIGHUP to all processes that have it as their controlling terminal. These processes form a session, but not all sessions have a controlling terminal. For your project, one possibility is therefore to start all the processes in their own terminal, created by script, screen, etc. Kill the terminal emulator process to kill the contained processes (assuming they haven't seceded with setsid).

You can provide more isolation by running the processes as their own user, who doesn't do anything else. Then it's easy to kill all the processes: run kill (the system call or the utility) as that user and use -1 as the PID argument to kill, meaning “all of that user's processes”.

You can provide even more isolation, but with considerably more setup by running the contained processes in an actual container.

Linux – Internal organization (with regard to family relations) of processes in Linux

Your confusion stems from mixing two things: (1) keeping the process descriptors organized, and (2) the parent/child relationship.

You don't need the parent/child relationship to decide which process to run next, or (in general) which process to deliver a signal to. So, the Linux task_struct (which I found in linux/sched.h for the 3.11.5 kernel source) has:

struct task_struct __rcu *real_parent; /* real parent process */
struct task_struct __rcu *parent; /* recipient of SIGCHLD, wait4() reports */
/*
 * children/sibling forms the list of my natural children
 */

struct list_head children;  /* list of my children */
struct list_head sibling;   /* linkage in my parent's children list */

You're correct, a tree struct exists for the child/parent relationship, but it seems to be concealed in another list, and a pointer to the parent.

The famed doubly-linked list isn't obvious in the 3.11.5 struct task_struct structure definition. If I read the code correctly, the uncommented struct element struct list_head tasks; is the "organizing" doubly-linked list, but I could be wrong.

Best Answer

Related Solutions

Process descendants

Linux – Internal organization (with regard to family relations) of processes in Linux

Related Question