The old Sperry operating system from Unisys for successors to the 1108 computer 
has temporary files that are accessible only to the process that creates them.  
Such files can be treated as "directories," even though the file system on such 
machines is not tree-structured.  Space allocated to temporary files is 
reclaimed when the file is no longer needed (as when the process terminates) 
and when the system unexpectedly reboots with processes running.  This is 
interesting as there is no record of such files in the file naming system 
except, perhaps, for a few orphaned "granule" tables that map file relative 
addresses to device relative addresses.  The security of temporary files on 
such systems is absolute as they cannot be accessed through the file naming 
system.  Yet they are named exactly as are files that are accessible through 
the file naming system.  The beauty of such temporary files is that they take 
care of themselves when abandoned:  they don't hang around as entries in a 
catalogue waiting for some process to dispose of them.
  ----- Original Message ----- 
  From: Leichter, Jerry 
  To: ljknews 
  Cc: sc-l@securecoding.org 
  Sent: Friday, December 29, 2006 18:56
  Subject: Re: [SC-L] temporary directories


  | Not on Unix, but I tend to use temporary names based on the Process ID
  | that is executing.  And of course file protection prevents malevolent
  | access.
  | 
  | But for a temporary file, I will specify a file that is not in any
  | directory.  I presume there is such a capbility in Unix.
  You presume incorrectly.  You're talking about VMS, where you can
  open a file by file id.  The Unix analogue of a file id is an
  inode number, but no user-land call exists to access a file that
  way.  You can only get to a file by following a path through the
  directory structure.

  In fact, all kinds of Unix code would become insecure if such a
  call were to be added:  It's a common - and reasonable - assumption
  that accessing a file requires access to the (well, a) directory in
  which that file appears (not that it isn't prudent to also control
  access to the file itself).

  One can argue this both ways, but on the specific matter of safe
  access to temporary files, VMS code that uses FID access is much
  easier to get right than Unix code that inherently has to walk
  through directory trees.  On the other hand, access by file id
  isn't - or wasn't; it's been years since I used VMS - supported
  directly by higher-level languages (though I vaguely recall that
  C had a mechanism for doing it).  A mechanism that requires
  specialized, highly system-specific low-level code to do something so
  straightforward is certainly much better than no mechanism at all,
  but it's not something that will ever be used by more than a
  small couterie of advanced programmers.
  -- Jerry

  _______________________________________________
  Secure Coding mailing list (SC-L) SC-L@securecoding.org
  List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
  List charter available at - http://www.securecoding.org/list/charter.php
  SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
  as a free, non-commercial service to the software security community.
  _______________________________________________
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________

Reply via email to