Re: README: three important security proposals

On Mon, 07 Feb 2000 06:57:34 MST, Tom Christiansen wrote:
> 1) ISSUE:  People think that open(TMP, ">/tmp/foo.$$") is fine.
>
>    FIX:    Point out in the perlfunc/open doc that this is not
>            secure, especially in directories anyone can delete
>            anything from.  Refer readers to a new section in the
>            perlsec manpage on secure Perl programming that would
>            cover diverse non-trivial and non-obvious tmpfile issues.
>
>
> 2) ISSUE:  By relying upon native semantics for tmpfile and tmpnam
>            (and making them more than somewhat hard-to-find), Perl
>            is at the mercy of each platform's peculiar problems.
>            For example, on SunOS and SysVr3-derived code, tmpfile
>            appears to use fopen(path, "w+"), which is problematic.
>
>    FIX:    We should include in Perl implementations for these
>            routines whose provenance we can guarantee, irrespective
>            of platform.  That way we *know* what we're getting.
>            This is like the matter of using our own globbing code
>            instead of calling out to a native executable.  The
>            fixes suggested for issue #1 should satisfy the "hard
>            to find" part here.
>
>
> 3) ISSUE:  There exists no standard equivalent in Perl to the libc
>            functions mktemp(3), mkstemp(3), mkstemps(3), or
>            mkdtemp(3).  These functions all receive as an argument
>	    a mutable template string, thus permitting the program
>	    to specify the directory in which the temp files shall
>	    occur, and the general format of their names.
>
>    FIX:    Add some or all of these templatizing functions to the
>            standard Perl distribution.  Define tmpfile() in terms
>            of mkstemp(), with an unlink().  These can all go in
>            one module, not scattered about as IO::File::tmpfile()
>            and POSIX::tmpnam() currently are.  Although there is
>            a CPAN module for some of this, that module is buggy.
>            Include doc fixes per issue #1.

That's a nice summary.

Now if someone will be so kind as to add the necessary code to IO.xs,
I'd be glad to put it in.


Sarathy
gsar@ActiveState.com

• Re: README: three important security proposals by Tom Christiansen
• README: three important security proposals by Tom Christiansen
• Re: README: three important security proposals by Gurusamy Sarathy