LinuxSA Mailing list archives

  From: Daryl Tester <dt@picknowl.com.au>
  To  : David Newall <davidn@rebel.net.au>
  Date: Sat, 29 Apr 2000 20:34:28 +0930

Re: Protecting files against power failure

David Newall wrote:

[I originally wrote:]
>> (although, of course, this shouldn't affect the shell's file
>> descriptor - care to hazard a guess why?).
[But later retracted after being enlightened with a hammer.]

> File descriptors can be shared amongst different processes.  Consider these
> two command sequences:
> 
>   bash$ some-process < some-file & some-process < some-file
>   bash$ (some-process & some-process) < some-file

File descriptors can be _inherited_ by child processes, as both your
above examples show.  They can't be passed to any arbitrary process.
To perform something like "cat < file", your atypical shell might
(very rudimentarily) perform:

1) fd = open("file", O_RDONLY);   /* open file for reading (? fd = #3 ?) */
2) fork();                        /* create child from parent process */

   /* In the child process */

3) dup2(fd, 0);                   /* Map file descriptor #3 onto #0 */
4) exec("cat");                   /* Execute the cat process. */

   /* In the parent process */

5) wait(&status);                 /* Wait for termination of child. */

In the real world, it's more complex than this, as we have to take
into account close-on-exec flags on file descriptors, signals,
possibly closing off fd's descriptor in the parent process, plus
the various permutations you described above with "(cmd & cmd) < foo"
et. al.  But the fact remains that a process can only inherit file
descriptors passed in from the parent.

>   bash$ exec 5> /dev/null
>   bash$ ./print <&5 &
>   [1] 1234
>   bash$ ./set 100 <&5
>   100
>   bash$ ./set -10 <&5
>   90
>   bash$ ./set 12345 <&5
>   12435
> 
> The numbers are printed by print, but as a result of something which set
> does.  This is a clear example of how one process CAN impact another (even
> though the implicit promise of Unix is that all processes are isolated from
> all others.)

But they aren't isolated.  They share a common parent, who passed in
a duplicated (but shared) file descriptor to the child process in each
case.

> When you need access to a file you signal that process and have it
> pass a file descriptor (using send()) to you.

This wouldn't work, because there would be no difference between a
process receiving (via recv()) a file descriptor ID, an arbitrary
integer, or just plain making up a number on the spot and read()'ing
and write()'ing to its heart's content.  Unless the FD's been open
for the process before it was exec'd, or it does the opening itself,
it won't be able to do jack.

> Well that's what you could do if you were evil.

Well, it's lucky I'm not, then.  :-|

Regards,
  Daryl Tester

-- 
LinuxSA WWW: http://www.linuxsa.org.au/  IRC: #linuxsa on irc.linux.org.au
To unsubscribe from the LinuxSA list:
  mail linuxsa-request@linuxsa.org.au with "unsubscribe" as the subject