At 6:56 PM -0500 12/29/06, Leichter, Jerry wrote:

> | 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 capability in Unix.

> You presume incorrectly.  You're talking about VMS, where you can
> open a file by file id. 

Actually, I was talking about using the FAB$V_TMD bit when creating
the file.

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

In Ada invoking <packagename>.CREATE with a null name will do the
trick, although if your VMS experience ended before 1983 you would
not have run into that.  But how to program easily against VMS V4.1
when the latest version is VMS V8.3 is not a typical problem.

I gather you are saying that the innards of Unix will force creation
of an unwanted directory entry on the Ada implementation of the required
null name support for <packagename>.CREATE .  The Ada implementation
could rely on exclusive access to the file (surely Unix has that, right?)
coupled with whatever Unix has that passes for the FAB$V_DLT bit to
delete the file on Close (such as at <insert Unix words for image rundown>).

But these are problems that have been solved by those who provided the
Ada implementation (ACT and Aonix come to mind for Unix), and thus are
not an issue for the high level language programmer.
Larry Kilgallen
Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Reply via email to