Re: another /tmp race: `perl -e' opens temp file not safely

[deraadt () CVS OPENBSD ORG (Theo de Raadt)]

> If a lot of third party programs mktemp() and then fopen (..., "w")
> and it is easy to make mktemp() work more securily (i.e., securily
> for non-setgid programs) _why_ not do it?  It's no trick, it will
> work as it did earlier.  It is not going to break anything.  It does
> not contradict to any standards, I guess, too.

But it is so trivial to fix code:

        FILE *fp = NULL;
        int fd = -1;
        char *nam = strdup("/tmp/fooXXXXXXXXXX");

        if (nam == NULL)
                return (NULL);
        if ((fd = mkstemp(nam)) == -1) {
                close(fd);
                free(nam);
                return (NULL);
        }
        if ((fp = fdopen(fd, "w+")) != NULL) {
                free(nam);
                return (fp);
        }
        close(fd);
        unlink(nam);
        free(nam);
        return (NULL);

etc etc whatever.

It's just code like that; if anyone doesn't understand how it works
perhaps they shouldn't be working in security 'cause they are never
going to be able to ensure they are writing secure code themselves.

> However, what you are doing is just
> making _your_ code correct.  I don't see that it's anything
> specifically related to security:

Uhm, those are exactly the same thing.  Correct code does not have
unwanted side effects.  It doesn't have unwanted side effects like
buffer overflows which permit code to be run off the stack.

Secure code does what it needs to do correctly, and nothing more.

So why don't people fix code so that it is correct?  Or, why don't
people learn how to write correct code first?