httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: [patch] 1.3.15 ap_os_is_path_absolute
Date Sat, 04 Nov 2000 22:37:11 GMT
Brian... I apologize this fell into my spam trap, fortunately
I always take a quick browse through before I flush it every
weekend.  I certainly didn't mean to ignore your comments :-(

> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
> Sent: Thursday, November 02, 2000 10:42 PM
> 
> On Thu, 2 Nov 2000 08:20:56 -0600, William A. Rowe, Jr. wrote:
> 
> >> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
> >> Sent: Thursday, November 02, 2000 3:58 AM
> >> 
> >> [...] To produce a canonical file name you must
> >> map all possible ways of specifying a particular file to a 
> single value.
> >> Considering that the CWD can change, the resulting value MUST be an
> >> absolute path, including the drive letter if on a platform 
> >> that uses them.
> >
> >YES, but... we are entirely rewriting canonical names for Apache 2.0.
> >It is -too much- for 1.3 and the associated audit involved.
> 
> So you admit the OS/2 ap_os_canonical_filename() is in fact correct?

No, I admit that not a single mechanism we are using is anywhere near
ideal to address the problems.  Your's isn't better or worse, simply
different, and I don't want to change semantics at this very late
stage of the 1.3.x game -if- it is working.  My observations indicate
that Win32 is working, your's indicate that OS2 is working.  We can
leave well enough alone.  I believe that we should never have had the
divisions between ap_make_full_path and ap_os_canonical_filename, and
I believe that there is such a thing as having a canonicalize filename
that will accept and return relative paths.

> >It's too computationally intensive unless we cache the 
> elements that have
> >already been reformatted.  That's how canonical is 
> prototyped for 2.0.
> 
> Resolving relative paths is nothing compared to the expense 
> of looking up
> each component in the file system which is done in
> ap_os_systemcase_filename() which is called by
> ap_os_case_canonical_filename() which is called by
> ap_os_canonical_filename().

I agree it's less than ideal.  That's why we start from scratch
in 2.0, and right down into directory_walk.

> >> No, that's not how I'd rather do it, I'd prefer to find the 
> >> correct fix.  Why doesn't ap_os_is_path_absolute() look for 
> >> backslashes on Win32?
> >
> >That was my proposed solution #1 - and I didn't veto, find 4 +1's to 
> >push over my own -1 [not vetoing] and I will commit exactly that.
> 
> Why are you against it? I'd rather convince you to change your vote as
> nobody else seems to be taking an interest in the issue.

My logic is really, really simple.  I don't want to store backslashes.
Anything that the core or module authors used to process paths should be
absolutely consistent.  Look at the Netware patch that was just required.
If a backslash is hiding out there, it's a problem.

> Here's how I see it in a nutshell. You are trying to solve a 
> problem. The
> problem is that windows users can't use backslashes in their 
> config files.
> This is on the stable tree so the fix should be as simple & clear as
> possible with no side effects. This leaves 2 options that I can see:
> 
> 1) Make ap_os_is_path_absolute() check for both types of slashes.
> 2) Use ap_fix_slashes() as I previously posted.

I just explained the both slashes issue.  I hate the context ap_fix_slashes
because we must do more than that.  We have to strip multiple trailing
periods, for device names, and other platforms may have additional issues
to address.  We are starting over with 2.0, let's work together to do that
the right way from the getgo.
 
> I don't buy your namespace pollution argument against (2). 
> Whoever said we
> can't/shouldn't add new functions?

Just one hack's opinion.

> >IMHO, move the DosGetFullPath over to ap_make_full_path() in
> >an #ifdef OS2 escape, and everyone shares predictable results.
> 
> I can't MOVE the "DosGetFullPath" call as it does most of the work of
> canonicalization, not just resolving relative paths. In fact 
> the only thing
> it doesn't handle is case.

Fair enough (your commit indicates you looked very closely at this
whole issue from OS2's perspective) and both of our platforms are
working respectably.  If I slammed on too much security on Win32,
then oh well, I'd hate to have it the other way around.

> >We _will_ bang out a single source for canonical under APR for 
> >both Win32 and OS2 (with a few #ifdef escapes for long names 
> >or whatnot), and a single theory for all platforms (even the
> >purish Un*x ones can have case insensitive, case preserving
> >mount points today.)
> 
> Ouch, yes, that could get very tricky. At least on OS/2 & 
> Win32 you can ask
> what file system a drive is (although that's still no 
> guarantee, a "LAN" FS
> could be a case sensitive Samba share). On unix you can 
> change file system
> part way through a path and I don't know of any standard way 
> of finding out
> what it is.

That's why I need your help, Fred's, Jeff's and the others
who have experience with convoluted file systems.

> >Look for that code this weekend, but 
> >please don't pull me out to reargue an issue I've spent over a 
> >full month auditing, debating, coding, and debugging.  It's a
> >more predictable by an order of magnitude today.  And that's
> >plenty for the 1.3.x family.
> 
> That's hardly fair. Just because you've put in a lot of time 
> & don't want
> to put in any more, we just have to accept that you're right?

NO.  I just don't want to single step this code anymore.  I'm near
certain that Win32 works, your patch reflects you are certain as
well about OS2.  It's a stable code base, I don't want to risk
loosening any tests.  I have no problem that things don't work in
a subsequent release because it's overly secure.  I would have a
serious problem if a hole was introduced.
 
> I'm not keen on a protracted debate either but you're making 
> my code out to
> be the bad guy when it is in fact the better implementation. 
> At very least
> you should be using #ifdef WIN32 rather than #ifndef OS2 as 
> this change is
> only required to fix a windows problem, right?

I'm sorry if I came off that way, I did -not- mean to.  I'm more
sorry this response was so belated, it would have had an answer in
about two minutes if it wasn't for the fuzzy spam test logic in
MS outlook :-(.   And in answer to your comment about the #ifdef,
in fact Netware follows the unix/win32 pattern (and I'm not arguing 
that it's better or worse than OS2.)  OS2 is unique, and I'm fine
with that.  Let's try to get some serious code sharing together
for the canonical parsing for Apache 2.0, write it from scratch, and
come to agreement about how it aught to do what we agree it should.



Mime
View raw message