Hylafax Developers Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[hylafax-devel] Re: Supported Platforms/Security mods?
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