httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Replacement for mktemp and httpd_monitor
Date Thu, 28 Dec 1995 00:50:36 GMT
Paul Richards wrote:
> 
> In reply to Jim Jagielski who said
> > 
> > Paul Richards wrote:
> > > http_monitor has to have the same mkatemp as
> > > Apache does, this isn't consistent with using a scoreboard name that
> > > arbitrary third party tools can access.
> > 
> > Ahh, but it _is_, since the scoreboard name can be totally defined by
> > a few lines of code.
> 
> But, third party tools will have to share code with Apache to ensure
> they are using the same heuristic for the creation of the filename. That's
> not good because each time that code is changed in Apache all third party
> authors have to upgrade their code too.

Feh... That's assuming that the heuristic is:

  1. Hard to code
  2. Get's changed alot

#1 definately isn't true (the description is longer than the code) and
#2 isn't true either. Why would we change the heuristic?? By provding the
exact code that Apache uses, 3rd paryt apps are _assured_ OS independence.

> 
> > > Strings should be malloced at run time, avoids problems with
> > > fixed length buffers and reduces the executable image and generally make
> > > better use of memory.
> > 
> > I don't see that. mallocs are expensive. And fixed length buffers are only
> > a problem when you allow arbitrary data. This diffs don't.
> 
> But these strings are only malloced *once* at startup. There's no
> performance penalty, other than a slightly slower startup. I think
> performance would actually be faster since you then pass pointers
> on the stack instead of big strings.

You pass the pointers whether they are malloced or whether they are
statics.

> 
> > > Also makes security holes with sprintf a non-issue
> > > because strings aren't on the stack.
> > 
> > Again, since we limit things in the code, we can use sprintf. As I see
> > it, the diffs avoid overflows by limiting the output width in the
> > sprintf statement to be exactly the size required. There's nothing
> > wrong with using sprintf if you can assure things are right, which is
> > what is being done.
> > > 	
> > > 	sprintf(lock_fname, "%s.%8d", LOCK_FILE, pid);
> > 
> > Isn't this what the diffs do anyplace, in a way? Only we use a function
> > call, which is better since it assures those reading the code that there's
> > a consistant way of doing it that's being used.
> 
> Not in my opinion. I see no reason not to simply print out a fixed
> string with the decimal pid appended to it.

Huh? That's exactly what's being done! Have you actually _looked_ at the
diffs before commenting on them? Ohhh... the diffs use hex instead of
decimal... Ok, easy change. Took 2 seconds... Next...

> The string can be
> configurable so ti's path and/or name can be changed according to the
> admins taste  but it would have a default which third party code 
> writers can rely on. The config files are "standard" anyway so the actual
> filename used can be easily determined just by reading it from
> the config file and appending the pid.

The scoreboard name isn't in the config files at all. It's hardcoded into
apache.

> 
> The existence of a function call is the over-engineering I was referring 
> to. there's nothing more consistent than a straight text string. A function
> is not consistent if that function has to be copied in every program that
> has to access that file. I don't see thatthe added function buys us
> anything except added complexity.

Hello! The function doesn't have to be copied anywhere. It was "created"
as a function to make things easier to understand and more modular. We
can define a "standard" "temp" file for use by Apache. Right now, only 2
such files are used: scoreboard and the lockfile, but more may happen.
Are you honestly saying it's better to add the same exact lines of code
many places in a distribution rather than making it a function and
calling it? The added function allows for an OS-independant way of
defining "temporary" filenames for use by (and for) Apache, instead of
relying on such unknowns as 'mktemp'. The actual code used is simple,
intuitive and very very unlikely to change. What's wrong with that?

Let's go back aways and remember _why_ the patch was created: it was due
to the fact that the actual scoreboard name varied from OS to OS, due to
it being "named" by mktemp(). This made "3rd party apps", such as
httpd_monitor, unable to be OS-independant since httpd_monitor _needed_
to redo what mktemp() did. But there was no way for httpd_monitor to know
how mktemp() did it's job. The solution was obvious: create our _own_
version of mktemp that is simple, intuitive and does the job. Make the
code as simple as possible (it's what? 2 lines now?) so that it's easy
for 3rd party apps to include it in there code (eg: "This is how the
name of the scoreboard file is generated <insert code here>"). Since we
are replacing a function, it makes sense to do so _with_ a function, esp
since future versions of Apache may make use of it. Also, it make it _very_
easy to see _exactly_ what's being done. Also, the code itself assures that
buffer overflows aren't possible by checking the string and forcing the
size to prevent such overflows. It does the job, fixes the problem, and
introduces no buffer overflow/security concerns. The cost? A function
call... Now where exactly is the major problem with the implementation?
-- 
Jim Jagielski  << jim@jaguNET.com >>   |           "Wind the frog!"
  **  jaguNET Access Services  **      |       - Woody (from Toy Story)
++       Email: info@jaguNET.com      +++        Voice:  410-931-3157       ++
++       http://www.jaguNET.com/      +++         Data: 410-931-7060        ++

Mime
View raw message