[hylafax-devel] Re: Supported Platforms/Security mods?

[Robert Colquhoun <rjc@trump.net.au>]

At 11:04 AM 6/13/00 -0700, Andy Sparrow wrote:
>On Thu, Jun 08, 2000 at 05:35:48PM +1000, Robert Colquhoun wrote:
> > snprintf and strncpy are ok.  The only thing to think about is that 
> hylafax
> > is written in C++ and it might be better to use the included fxStr 
> class or
> > perhaps the ansi string class than a straight char buffer.
>
>Yes, that would seem a better long-term solution. However, I'm /way/
>more comfortable with K&R C than ANSI - and I never got around to
>C++ at all...
>
>Therefore, I really only spent time on ensuring that printing/copying
>into char buffers is restricted to the bounds of that buffer (via
>'snprintf()', 'vsnprint()' and 'strlcpy()') ;-)

Even if you just find and list the problems for someone else to fix would 
be helpful.


> > mkstemp() is a problem though, on HPUX at least it is limited to 26 files
> > open at once.
>
>Hmm. Maybe it'd be better not to touch this then. Or make any change
>FreeBSD-specific (e.g. in the FreeBSD port's 'patches' directory).
>
>I presume that there's no way to tweak 'configure' into using a
>portability function (e.g. from "port") in preference to one provided
>by the system?
>
>Better look at that, I guess..

I did some work on this awhile back, i just did a quick grep on the source 
code, there is:
         1 use of tmpfile()
         11 uses of mkstemp()
         2 uses of mktemp()
         0 uses of tempnam()
         0 uses of tmpnam()

... i remember trying to get rid of the mktemp() calls but because of the 
way it was written(...insert diatribe about original author...) i could not 
do it without rewriting the whole thing.


> > tmpfile() is the preferred call - but this can sometimes be
> > annoying if you only want a file handle rather than a FILE*......this
> > stopped me from converting to all tmpfile() calls previously...i think i
> > got rid of most of the mktemp() stuff a year or so ago though.
>
>On some platforms at least, 'tmpfile' and friends are much less
>secure than 'mkstemp', judging by this excerpt from the BSD 'tmpfile'
>man page:

None of the temporary file routines are very good - for instance on linux 
upto glibc 2.07 mkstemp created all its temporary files world writeable.

On a modern system though i should think mkstemp() and tmpfile() would be 
about even though, tmpfile() has the plus it is a posix standard but the 
big disadvantage it creates FILE*.  mkstemp() has the advantage it creates 
an int filehandle but the disadvantage that it is poorly implemented or 
depreciated outside the BSD world.


>         BUGS
>
>                 These interfaces are provided for System V and ANSI
>                 compatibility only.  The mkstemp(3) interface is
>                 strongly preferred.

..and tmpfile() is posix


>                 This implementation does not have these flaws, but
>                 portable software cannot depend on that.  In
>                 particular, the tmpfile() interface should not be
>                 used in software expected to be used on other
>                 systems if there is any possibility that the user
>                 does not wish the temporary file to be publicly
>                 readable and writable.

...unfortunately the same is true of mkstemp() on other platforms.

Basically the policy i was following till now was:
         - mkstemp() and tmpfile() are both ok.
         - tempnam(), tmpnam() and mktemp() should *not* be used.

Perhaps what is need is a wrapper function to create temporary files which 
chooses the best implementation mkstemp() or tmpfile() depending on the 
platform.

- Robert




____________________ HylaFAX(tm) Developers Mailing List ____________________
 To unsub: mail -s unsubscribe hylafax-devel-request@hylafax.org < /dev/null