Hylafax Developers Mailing List Archives

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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()') ;-)

> 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..

> 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:

	BUGS

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

		There are four important problems with these
		interfaces (as well as with the historic mktemp(3)
		interface).  First, there is an obvious race between
		file name selection and file creation and deletion.
		Second, most historic implementations provide only
		a limited number of possible temporary file names
		(usually 26) before file names will start being
		recycled.  Third, the System V implementations of
		these functions (and of mktemp(3)) use the access(2)
		function to determine whether or not the temporary
		file may be created.  This has obvious ramifications
		for setuid or setgid programs, complicating the
		portable use of these interfaces in such programs.
		Finally, there is no specification of the permissions
		with which the temporary files are created.

		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.

> >         In other words, can (should) I assume reasonably modern
> >         OSs that have all the above as native functionality in libc
> >         (or where-ever), or does this all need to be done conditionally
> >         because someone, somewhere is still running SunOS 3.x on
> >         a Sun2 and wants to use it as a HylaFAX server? ;-)
> 
> There is the port directory to build emulation routines for older 
> platforms.  As long as the defaults work reasonably for most modern 

I'll gen up on what exactly I can do with autoconf before I touch
this.

> Could you put beta2 in as a replacement for 4.0pl2(...i can't remember if 
> this has the faxalter security fix or not, but it is an easy patch)

It does have the faxalter fix in it, and a number of other very
useful-looking things ;-)

I did the work against beta2 as suggested, but with the addition
of the libtiff-v3.5-interfaces patch and the cvtDataTime patch.

Unfortunately, the libtiff-interfaces patch (necessary to build on
a "modern" FreeBSD system, where libtiff-3.5.5 is the flavour)
seems to preclude use of Dimitry's RTN patch for beta2.

> The current plan for beta 3, in my head is:
>          - suse ip-source routing patches
>          - fix big manpage cgi-bin security hole..yes this is still not 
> done:-(

Errr, I'm sorry, manpage cgi-bin security hole - I'd not previously
heard about that. Any reference for that, keyword I can search on,
whatever?

What's the issue?


>          - dmitrys patches.
>          - stuff that i have forgot about

Err, could you list those, please? ;-)


Thanks for the response.

Cheers,

AS


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



Home
Report any problems to webmaster@hylafax.org

HylaFAX is a trademark of Silicon Graphics Corporation.
Internet connectivity for hylafax.org is provided by:
VirtuALL Private Host Services