Re: GNAT 3.14p and Red Hat 7.2

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

Florian Weimer <fw@deneb.enyo.de> wrote:
: "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
: 
:>> The first warning is issued because the code *does* contain a security
:>> problem (your Ada application will be affected only if it uses
:>> temporary files, though). Ignoring it won't make it go away. ;-)
:>
:> More correctly, one should say "your Ada application will be affected
:> only if it uses GNAT.OS_Lib.Create_Temp_File."
:>
:> One can certainly safely use temporary files in Ada programs.
: 
: But not using the mechanism in A.8.2(4). :-/

I recall a discussion of OS security in the Minix book
by Tanenbaum, where he points out that you should not believe
in security because your system manual tells you some part
of the system has been secured. On the contrary, the mechanism
should be open to cracking attempts, to be tested.

On the surface, this seems unrelated, and mkstemp() (or whatever
its name is) is open to testing of all kinds.
But the mindset seems related, at least to me. If programmers feel 
they have written a secure program because they are told their
compiler doesn't use insecure OS facilities, I wouldn't, necessarily,
as a user of their program.  Proven security...?

Improved security due to the removal of one possible hole?
Let me argue in favour of documenting possible holes. 
If program writers learn to pay attention to the outcome
of the compilation process, and they must, once they now
even an Ada program doesn't just use RM virtuality,
they will care about what OS facilities operate behind the
scenes.

Who knows what will happen to a running Ada program if the
OS kernel supports modifying the hardware clock...
I don't, right know, but if my program depends on that
device, I will pay attention, and hope to find a note
somewhere near the Clock documentation.

- Georg