To: gopher@complete.org
Subject: [gopher] Re: Security problems in gopherd (Was Security alert)
References: <20010117181031.A16810@mothra>
From: John Goerzen <jgoerzen@complete.org>
Date: 18 Jan 2001 01:15:49 -0500
In-Reply-To: <20010117181031.A16810@mothra>
Message-ID: <87ely1jsh6.fsf@complete.org>
Lines: 39
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.1 (Channel Islands)
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


One option would be to create a directory in /tmp, mode 0700, and put
all files in it.  This would allow the more-portable tempnam() to
continue to be used.  In the course of auditing sprintf()s, I did come
across one or two open() calls for /tmp files and added O_EXCL to the
list as a temporary measure...

-- John

David Allen <s2mdalle@titan.vcu.edu> writes:

> John and others - 
> 
> There is also still the remaining issue of several uses of the
> tempnam() call in gopherd.c.  I've been aware of them and meaning to
> fix them for a while, but they seem to store the name of the temp file
> in a global called ASKfile.  When I was looking at it, I wasn't able
> to determine at the time what other dire consequences I'd cause if I
> changed to a different call where the tempfilename wasn't stored in
> ASKfile, so I haven't changed it yet.
> 
> It seems though that in some places particularly for ASK data, that
> the daemon stores the response in a temporary file and then lets other
> areas of the code reopen and read that.  (Hence the need for the temp
> filename I think)  mkstemp looks like a possible replacement since
> there's a way to get the temp filename out of it.
> 
> -- 
> David Allen
> http://opop.nols.com/
> ----------------------------------------
> DISCLAIMER: Regardless of what you read below, I agree with you. 
> 
> 
> 

-- 
John Goerzen <jgoerzen@complete.org>                       www.complete.org
Sr. Software Developer, Progeny Linux Systems, Inc.    www.progenylinux.com
#include <std_disclaimer.h>                     <jgoerzen@progenylinux.com>