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. _______________________________________________
