You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@algroup.co.uk> on 1997/08/10 14:50:36 UTC
Win32 name canonicalisation
Here's a not particularly efficient implementation of name
canonicalisation for Win32. Now all we need to do is figure out where to
slot it :-)
It isn't Apache-ised, just written as a simple test console program.
Cheers,
Ben.
#include <windows.h>
#include <stdio.h>
#include <assert.h>
void sub_canonical_filename(char *szCanon,const char *szFile)
{
char buf[_MAX_PATH];
int n;
char *szFilePart;
n=GetFullPathName(szFile,sizeof buf,buf,&szFilePart);
assert(n);
assert(n < sizeof buf);
WIN32_FIND_DATA d;
HANDLE h=FindFirstFile(buf,&d);
assert(h != INVALID_HANDLE_VALUE);
FindClose(h);
if(szFilePart != buf+3) // "x:\" == 4
{
char b2[_MAX_PATH];
assert(szFilePart > buf+3);
szFilePart[-1]='\0';
sub_canonical_filename(b2,buf);
strcpy(szCanon,b2);
strcat(szCanon,"/");
strcat(szCanon,d.cFileName);
}
else
{
strcpy(szCanon,buf);
szCanon[2]='/';
szCanon[3]='\0';
strcat(szCanon,d.cFileName);
}
}
char *canonical_filename(const char *szFile)
{
char buf[_MAX_PATH];
sub_canonical_filename(buf,szFile);
strlwr(buf);
return strdup(buf);
}
void main(int argc,char **argv)
{
char *szFile=argv[1];
printf("%s\n",canonical_filename(szFile));
}
--
Ben Laurie Phone: +44 (181) 994 6435 Email:
ben@algroup.co.uk
Freelance Consultant and Fax: +44 (181) 994 6472
Technical Director URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd, Apache Group member (http://www.apache.org)
London, England. Apache-SSL author
Re: Win32 name canonicalisation
Posted by Ben Laurie <be...@algroup.co.uk>.
Alexei Kosut wrote:
>
> On Sun, 10 Aug 1997, Ben Laurie wrote:
>
> > Here's a not particularly efficient implementation of name
> > canonicalisation for Win32. Now all we need to do is figure out where to
> > slot it :-)
> >
> > It isn't Apache-ised, just written as a simple test console program.
>
> One major problem with this (besides the fact that it's written in C++;
> it took me twenty minutes of trying to figure out why it wasn't compiling
> as a C file before I realized this) is that it doesn't work when a file
> doesn't exit (Windows pops up an error). And Apache likes to deal with
> files that don't necessarily exist.
Sorry about the C++, though I did try to make it mostly C.
Hmmm ... I forgot to check it on nonexistent files - I'll see if I can
fix it.
>
> Ideally, I'd like to see something like this at the beginning of
> directory_walk, that actually modifies r->filename. That way, not only
> will <Directory> and <Files> work correctly, but any module that keys off
> r->filename won't be made insecure through the use of 8.3 filenames.
Sounds good.
>
> I'm not sure that calling strlwr() is a good idea. It avoids having to
> make all the strcmps into strcasecmps, but it means that we'd have to
> ensure that all the <Directory>, etc... entries are also strlwred (which
> might not be so bad).
Well, I did it more to show where it would be done, than to make the
statement that it should be done. +1 on strlwring <Directory> et al.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: Win32 name canonicalisation
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 11 Aug 1997, Ben Laurie wrote:
> We can blame MS for the drive letters :-)
NT 5.0 will have mount points. And symlinks. It actually sounds like
it's going to have most of unix. Except for the nitty gritty parts, which
makes it annoying.
I think a component by component solution is required to properly handle
all the cases... it has to be integrated into directory_walk.
Dean
Re: Win32 name canonicalisation
Posted by Alexei Kosut <ak...@organic.com>.
On Mon, 11 Aug 1997, Ben Laurie wrote:
> Alexei Kosut wrote:
> > Two concerns: First, FindFirstFile() expands out * and ?. Should we have
> > the function (how about os_canon_filename() as a name?) reject filenames
> > with those in it, or should we just let it expand them>
>
> This makes it easy to trawl for hidden files, so perhaps we should do
> something about it. Can they be escaped?
Not to my knowledge. I tried a few obvious escape characters, but it
didn't seem to work.
[...]
> We can blame MS for the drive letters :-)
So you think if we called up Bill and complained, he'd change it? :)
> Seriously, you haven't got a full path without a drive letter, so I
> can't see that it is a problem.
I suppose.
> I don't see why we need to add REG_ICASE - we just state that canonical
> filenames are all lowercase. Hmmm ... but perhaps the PATH_INFO bit
> should not be lowercased.
It's slightly counter-intuitive for the canonical Apache filenames to be
of a different case than the Windows case. I can easily see (and it makes
sense) people creating a directory called "Foo" and putting <Directory
/Foo> in their config file. For <Directory>, we can call
os_canon_filename() on it, but for regex, we have to add a REG_ICASE.
Actually, considering this a bit... I'm not actually sure strlwr() is
neccessary. If we call os_canon_filename() (or whatever) on r->filename,
and we've called it on all the <Directory> and <Files> sections, and we
use REG_ICASE, then there shouldn't be any problems with different-case
matching, since they would both now conform to Windows' perferred case,
right? Unless someone changes the case of a directory's name between
when Apache was started and when a request comes in.
But at any rate, if we put os_canon_filename() after get_path_info(), as
I suggested, we wouldn'[t have to worry about PATH_INFO, since it would
already be set using the case from the URL.
-- Alexei Kosut <ak...@organic.com>
Re: Win32 name canonicalisation
Posted by Ben Laurie <be...@algroup.co.uk>.
Alexei Kosut wrote:
> Two concerns: First, FindFirstFile() expands out * and ?. Should we have
> the function (how about os_canon_filename() as a name?) reject filenames
> with those in it, or should we just let it expand them>
This makes it easy to trawl for hidden files, so perhaps we should do
something about it. Can they be escaped?
> Second, <DirectoryMatch> and <FilesMatch>. When GetFullPathName() is
> called, it adds a drive letter. So a <Directory> match that does not have
> one (which will currently work - it will match the drive Apache's run
> from) will never match. For <Directory> and <Files>, fine, we can call
> os_canon_filename() on them before we add them in (that will help with
> the case matching, too). But what we we do with regexes? We should add
> REG_ICASE to regcomp() so that the case matching is insensitive, but
> we're stuck with requiring drive letters to always be present. I don't
> see this as a big deal, but I don't know.
We can blame MS for the drive letters :-)
Seriously, you haven't got a full path without a drive letter, so I
can't see that it is a problem.
I don't see why we need to add REG_ICASE - we just state that canonical
filenames are all lowercase. Hmmm ... but perhaps the PATH_INFO bit
should not be lowercased.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: Win32 name canonicalisation
Posted by Alexei Kosut <ak...@organic.com>.
On Mon, 11 Aug 1997, Ben Laurie wrote:
> Actually, that wasn't quite perfect. I think this may be:
Yep, this one seems to work great. Thanks!
The question is where we want to put this. Here's my opinion: in
directory_walk, directly after the get_path_info() call (this way, the
path info won't be made lowercase). It would never be called if
r->filename is a "fake filename" (doesn't start with / or a drive
letter), but it shouldn't be called in that instance anyhow, so that's
fine.
Two concerns: First, FindFirstFile() expands out * and ?. Should we have
the function (how about os_canon_filename() as a name?) reject filenames
with those in it, or should we just let it expand them>
Second, <DirectoryMatch> and <FilesMatch>. When GetFullPathName() is
called, it adds a drive letter. So a <Directory> match that does not have
one (which will currently work - it will match the drive Apache's run
from) will never match. For <Directory> and <Files>, fine, we can call
os_canon_filename() on them before we add them in (that will help with
the case matching, too). But what we we do with regexes? We should add
REG_ICASE to regcomp() so that the case matching is insensitive, but
we're stuck with requiring drive letters to always be present. I don't
see this as a big deal, but I don't know.
Once we get this resolved, I can work up a patch.
-- Alexei Kosut <ak...@organic.com>
Re: Win32 name canonicalisation
Posted by Ben Laurie <be...@algroup.co.uk>.
Actually, that wasn't quite perfect. I think this may be:
#include <windows.h>
#include <stdio.h>
#include <assert.h>
void sub_canonical_filename(char *szCanon,const char *szFile)
{
char buf[_MAX_PATH];
int n;
char *szFilePart;
WIN32_FIND_DATA d;
n=GetFullPathName(szFile,sizeof buf,buf,&szFilePart);
assert(n);
assert(n < sizeof buf);
HANDLE h=FindFirstFile(buf,&d);
if(h != INVALID_HANDLE_VALUE)
FindClose(h);
if(szFilePart < buf+3)
{
strcpy(szCanon,buf);
szCanon[2]='/';
return;
}
if(szFilePart != buf+3)
{
char b2[_MAX_PATH];
assert(szFilePart > buf+3);
szFilePart[-1]='\0';
sub_canonical_filename(b2,buf);
strcpy(szCanon,b2);
strcat(szCanon,"/");
}
else
{
strcpy(szCanon,buf);
szCanon[2]='/';
szCanon[3]='\0';
}
if(h == INVALID_HANDLE_VALUE)
strcat(szCanon,szFilePart);
else
strcat(szCanon,d.cFileName);
}
char *canonical_filename(const char *szFile)
{
char buf[_MAX_PATH];
sub_canonical_filename(buf,szFile);
strlwr(buf);
return strdup(buf);
}
void main(int argc,char **argv)
{
char *szFile=argv[1];
char *szCanon=canonical_filename(szFile);
printf("%s\n",szCanon);
}
--
Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: Win32 name canonicalisation
Posted by Ben Laurie <be...@algroup.co.uk>.
Ben Laurie wrote:
>
> Alexei Kosut wrote:
> >
> > On Mon, 11 Aug 1997, Ben Laurie wrote:
> >
> > > Alexei Kosut wrote:
> > > > One major problem with this (besides the fact that it's written in C++;
> > > > it took me twenty minutes of trying to figure out why it wasn't compiling
> > > > as a C file before I realized this) is that it doesn't work when a file
> > > > doesn't exit (Windows pops up an error). And Apache likes to deal with
> > > > files that don't necessarily exist.
> > >
> > > Try this:
> >
> > This isn't really what we need, though. Here's what we need to be able to
> > do (~ represents an 8.3 filename):
> >
> > Input: /foo/ba~/baz
> > (foo exits, bar exists, baz exists)
> > Output: /foo/bar/baz
> >
> > Input: foo/ba~/bax
> > (foo exists, bar exists, bax does not exist)
> > Output: foo/bar/bax
> >
> > Input: fo~/ba~/baz
> > (foo exists, ba~ does not)
> > Output: foo/ba~/baz
> >
> > In other words, the parts of the path that exist, expand out. The parts
> > that don't, just leave as is. That's the most compatible with how
> > directory_walk works (AFAIK, it puts the directory that exists, plus the
> > file in that directory - existing or not - into r->filename, and the
> > remainder into r->path_info).
>
> Tchah! You might've told me in the first place. OK, I should've known.
> Not a trivial change...
OK, how's this:
#include <windows.h>
#include <stdio.h>
#include <assert.h>
void sub_canonical_filename(char *szCanon,const char *szFile)
{
char buf[_MAX_PATH];
int n;
char *szFilePart;
WIN32_FIND_DATA d;
n=GetFullPathName(szFile,sizeof buf,buf,&szFilePart);
assert(n);
assert(n < sizeof buf);
HANDLE h=FindFirstFile(buf,&d);
if(h != INVALID_HANDLE_VALUE)
FindClose(h);
if(szFilePart != buf+3)
{
char b2[_MAX_PATH];
assert(szFilePart > buf+3);
szFilePart[-1]='\0';
sub_canonical_filename(b2,buf);
strcpy(szCanon,b2);
strcat(szCanon,"/");
if(h == INVALID_HANDLE_VALUE)
strcat(szCanon,szFilePart);
else
strcat(szCanon,d.cFileName);
}
else
{
strcpy(szCanon,buf);
szCanon[2]='/';
szCanon[3]='\0';
strcat(szCanon,d.cFileName);
}
}
char *canonical_filename(const char *szFile)
{
char buf[_MAX_PATH];
sub_canonical_filename(buf,szFile);
strlwr(buf);
return strdup(buf);
}
void main(int argc,char **argv)
{
char *szFile=argv[1];
char *szCanon=canonical_filename(szFile);
printf("%s\n",szCanon);
}
--
Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: Win32 name canonicalisation
Posted by Ben Laurie <be...@algroup.co.uk>.
Alexei Kosut wrote:
>
> On Mon, 11 Aug 1997, Ben Laurie wrote:
>
> > Alexei Kosut wrote:
> > > One major problem with this (besides the fact that it's written in C++;
> > > it took me twenty minutes of trying to figure out why it wasn't compiling
> > > as a C file before I realized this) is that it doesn't work when a file
> > > doesn't exit (Windows pops up an error). And Apache likes to deal with
> > > files that don't necessarily exist.
> >
> > Try this:
>
> This isn't really what we need, though. Here's what we need to be able to
> do (~ represents an 8.3 filename):
>
> Input: /foo/ba~/baz
> (foo exits, bar exists, baz exists)
> Output: /foo/bar/baz
>
> Input: foo/ba~/bax
> (foo exists, bar exists, bax does not exist)
> Output: foo/bar/bax
>
> Input: fo~/ba~/baz
> (foo exists, ba~ does not)
> Output: foo/ba~/baz
>
> In other words, the parts of the path that exist, expand out. The parts
> that don't, just leave as is. That's the most compatible with how
> directory_walk works (AFAIK, it puts the directory that exists, plus the
> file in that directory - existing or not - into r->filename, and the
> remainder into r->path_info).
Tchah! You might've told me in the first place. OK, I should've known.
Not a trivial change...
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: Win32 name canonicalisation
Posted by Alexei Kosut <ak...@organic.com>.
On Mon, 11 Aug 1997, Ben Laurie wrote:
> Alexei Kosut wrote:
> > One major problem with this (besides the fact that it's written in C++;
> > it took me twenty minutes of trying to figure out why it wasn't compiling
> > as a C file before I realized this) is that it doesn't work when a file
> > doesn't exit (Windows pops up an error). And Apache likes to deal with
> > files that don't necessarily exist.
>
> Try this:
This isn't really what we need, though. Here's what we need to be able to
do (~ represents an 8.3 filename):
Input: /foo/ba~/baz
(foo exits, bar exists, baz exists)
Output: /foo/bar/baz
Input: foo/ba~/bax
(foo exists, bar exists, bax does not exist)
Output: foo/bar/bax
Input: fo~/ba~/baz
(foo exists, ba~ does not)
Output: foo/ba~/baz
In other words, the parts of the path that exist, expand out. The parts
that don't, just leave as is. That's the most compatible with how
directory_walk works (AFAIK, it puts the directory that exists, plus the
file in that directory - existing or not - into r->filename, and the
remainder into r->path_info).
-- Alexei Kosut <ak...@organic.com>
Re: Win32 name canonicalisation
Posted by Ben Laurie <be...@algroup.co.uk>.
Alexei Kosut wrote:
> One major problem with this (besides the fact that it's written in C++;
> it took me twenty minutes of trying to figure out why it wasn't compiling
> as a C file before I realized this) is that it doesn't work when a file
> doesn't exit (Windows pops up an error). And Apache likes to deal with
> files that don't necessarily exist.
Try this:
#include <windows.h>
#include <stdio.h>
#include <assert.h>
int sub_canonical_filename(char *szCanon,const char *szFile)
{
char buf[_MAX_PATH];
int n;
char *szFilePart;
WIN32_FIND_DATA d;
n=GetFullPathName(szFile,sizeof buf,buf,&szFilePart);
assert(n);
assert(n < sizeof buf);
HANDLE h=FindFirstFile(buf,&d);
if(h == INVALID_HANDLE_VALUE)
return 0;
FindClose(h);
if(szFilePart != buf+3)
{
char b2[_MAX_PATH];
assert(szFilePart > buf+3);
szFilePart[-1]='\0';
if(!sub_canonical_filename(b2,buf))
return 0;
strcpy(szCanon,b2);
strcat(szCanon,"/");
strcat(szCanon,d.cFileName);
}
else
{
strcpy(szCanon,buf);
szCanon[2]='/';
szCanon[3]='\0';
strcat(szCanon,d.cFileName);
}
return 1;
}
char *canonical_filename(const char *szFile)
{
char buf[_MAX_PATH];
if(!sub_canonical_filename(buf,szFile))
return NULL;
strlwr(buf);
return strdup(buf);
}
void main(int argc,char **argv)
{
char *szFile=argv[1];
char *szCanon=canonical_filename(szFile);
if(szCanon)
printf("%s\n",szCanon);
else
printf("%s does not exist.\n",szFile);
}
--
Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: Win32 name canonicalisation
Posted by Dean Gaudet <dg...@arctic.org>.
You also need to do it in the optimized case of sub_req_lookup_file.
Dean
On Mon, 11 Aug 1997, Alexei Kosut wrote:
> On Sun, 10 Aug 1997, Ben Laurie wrote:
>
> > Here's a not particularly efficient implementation of name
> > canonicalisation for Win32. Now all we need to do is figure out where to
> > slot it :-)
> >
> > It isn't Apache-ised, just written as a simple test console program.
>
> One major problem with this (besides the fact that it's written in C++;
> it took me twenty minutes of trying to figure out why it wasn't compiling
> as a C file before I realized this) is that it doesn't work when a file
> doesn't exit (Windows pops up an error). And Apache likes to deal with
> files that don't necessarily exist.
>
> Ideally, I'd like to see something like this at the beginning of
> directory_walk, that actually modifies r->filename. That way, not only
> will <Directory> and <Files> work correctly, but any module that keys off
> r->filename won't be made insecure through the use of 8.3 filenames.
>
> I'm not sure that calling strlwr() is a good idea. It avoids having to
> make all the strcmps into strcasecmps, but it means that we'd have to
> ensure that all the <Directory>, etc... entries are also strlwred (which
> might not be so bad).
>
> -- Alexei Kosut <ak...@organic.com>
>
>
Re: Win32 name canonicalisation
Posted by Alexei Kosut <ak...@organic.com>.
On Sun, 10 Aug 1997, Ben Laurie wrote:
> Here's a not particularly efficient implementation of name
> canonicalisation for Win32. Now all we need to do is figure out where to
> slot it :-)
>
> It isn't Apache-ised, just written as a simple test console program.
One major problem with this (besides the fact that it's written in C++;
it took me twenty minutes of trying to figure out why it wasn't compiling
as a C file before I realized this) is that it doesn't work when a file
doesn't exit (Windows pops up an error). And Apache likes to deal with
files that don't necessarily exist.
Ideally, I'd like to see something like this at the beginning of
directory_walk, that actually modifies r->filename. That way, not only
will <Directory> and <Files> work correctly, but any module that keys off
r->filename won't be made insecure through the use of 8.3 filenames.
I'm not sure that calling strlwr() is a good idea. It avoids having to
make all the strcmps into strcasecmps, but it means that we'd have to
ensure that all the <Directory>, etc... entries are also strlwred (which
might not be so bad).
-- Alexei Kosut <ak...@organic.com>
Re: Win32 name canonicalisation
Posted by Dean Gaudet <dg...@arctic.org>.
directory_walk works component by component already. It can do the
long/short stuff on each component. Regexes are dealt with after the
components, that was one of the semantic changes in my recent patch. The
only thing we can't handle this way is the initial location_walk that
occurs before translate_name (and which is thrown away by directory_walk).
But location_walk is about URLs not about filenames, so I don't think it's
an issue ...
Dean
On Thu, 14 Aug 1997, Ben Laurie wrote:
> Alexei Kosut wrote:
> >
> > On Thu, 14 Aug 1997, Dean Gaudet wrote:
> >
> > > - decree that shortnames are not valid components period. Do a long->short
> > > (this is the cheap one right?) conversion on all components and
> > > if they differ then deny access.
> >
> > Hmm. Not a bad idea. But it doesn't sound right? If I want long
> > filenames, and a long->short conversion differs, wouldn't I want to allow
> > access, not deny access? Unless the long name was less than 8.3
> > characters long, in which case they'd be the same.
>
> It doesn't work at all, surely. We can't long->short regexps for
> starters, and the scheme doesn't enforce the "shortnames are not valid
> components" idea, either.
>
> Cheers,
>
> Ben.
>
> --
> Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
> Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
> and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
> A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
>
Re: Win32 name canonicalisation
Posted by Ben Laurie <be...@algroup.co.uk>.
Alexei Kosut wrote:
>
> On Thu, 14 Aug 1997, Dean Gaudet wrote:
>
> > - decree that shortnames are not valid components period. Do a long->short
> > (this is the cheap one right?) conversion on all components and
> > if they differ then deny access.
>
> Hmm. Not a bad idea. But it doesn't sound right? If I want long
> filenames, and a long->short conversion differs, wouldn't I want to allow
> access, not deny access? Unless the long name was less than 8.3
> characters long, in which case they'd be the same.
It doesn't work at all, surely. We can't long->short regexps for
starters, and the scheme doesn't enforce the "shortnames are not valid
components" idea, either.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: Win32 name canonicalisation
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> I was told there's either a name->long function or a name->short function
> ... either is good enough, isn't it?
Yes, but only if we do it by components. Which we've already done.
Cheers,
Ben.
>
> Dean
>
> On Thu, 14 Aug 1997, Ben Laurie wrote:
>
> > Dean Gaudet wrote:
> > >
> > > Er, whatever works, I was quite tired last night :) But yeah I think I
> > > like idea that we just simply deny the use of shortnames unless the
> > > shortname is the same as the long name.
> >
> > Right - but how do we detect short names?
> >
> > Cheers,
> >
> > Ben.
> >
> > --
> > Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
> > Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
> > and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
> > A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
> > London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
> >
--
Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: Win32 name canonicalisation
Posted by Dean Gaudet <dg...@arctic.org>.
I was told there's either a name->long function or a name->short function
... either is good enough, isn't it?
Dean
On Thu, 14 Aug 1997, Ben Laurie wrote:
> Dean Gaudet wrote:
> >
> > Er, whatever works, I was quite tired last night :) But yeah I think I
> > like idea that we just simply deny the use of shortnames unless the
> > shortname is the same as the long name.
>
> Right - but how do we detect short names?
>
> Cheers,
>
> Ben.
>
> --
> Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
> Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
> and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
> A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
>
Re: Win32 name canonicalisation
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> Er, whatever works, I was quite tired last night :) But yeah I think I
> like idea that we just simply deny the use of shortnames unless the
> shortname is the same as the long name.
Right - but how do we detect short names?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant |Fax: +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: Win32 name canonicalisation
Posted by Dean Gaudet <dg...@arctic.org>.
Er, whatever works, I was quite tired last night :) But yeah I think I
like idea that we just simply deny the use of shortnames unless the
shortname is the same as the long name.
Dean
On Thu, 14 Aug 1997, Alexei Kosut wrote:
> On Thu, 14 Aug 1997, Dean Gaudet wrote:
>
> > - decree that shortnames are not valid components period. Do a long->short
> > (this is the cheap one right?) conversion on all components and
> > if they differ then deny access.
>
> Hmm. Not a bad idea. But it doesn't sound right? If I want long
> filenames, and a long->short conversion differs, wouldn't I want to allow
> access, not deny access? Unless the long name was less than 8.3
> characters long, in which case they'd be the same.
>
> -- Alexei Kosut <ak...@organic.com>
>
>
Re: Win32 name canonicalisation
Posted by Alexei Kosut <ak...@organic.com>.
On Thu, 14 Aug 1997, Dean Gaudet wrote:
> - decree that shortnames are not valid components period. Do a long->short
> (this is the cheap one right?) conversion on all components and
> if they differ then deny access.
Hmm. Not a bad idea. But it doesn't sound right? If I want long
filenames, and a long->short conversion differs, wouldn't I want to allow
access, not deny access? Unless the long name was less than 8.3
characters long, in which case they'd be the same.
-- Alexei Kosut <ak...@organic.com>
Re: Win32 name canonicalisation
Posted by Dean Gaudet <dg...@arctic.org>.
I haven't read this thread at all yet. But I did ask about this exact
problem while I was at the Usenix NT conference this week. I got answers
from a fellow @microsoft, and fellows from Softway (who make OpenNT). The
suggestions were:
- use a heuristic to detect shortname components -- the existance of a ~
when a component contains the ~ do the short -> long
conversion, otherwise assume it's canonical
- find the registry setting that disables shortnames on ntfs partitions,
dictate that webservers have to change this and run on ntfs
- decree that shortnames are not valid components period. Do a long->short
(this is the cheap one right?) conversion on all components and
if they differ then deny access.
I personally like the last one.
Dean
On Sun, 10 Aug 1997, Ben Laurie wrote:
> Here's a not particularly efficient implementation of name
> canonicalisation for Win32. Now all we need to do is figure out where to
> slot it :-)
>
> It isn't Apache-ised, just written as a simple test console program.
>
> Cheers,
>
> Ben.
>
> #include <windows.h>
> #include <stdio.h>
> #include <assert.h>
>
> void sub_canonical_filename(char *szCanon,const char *szFile)
> {
> char buf[_MAX_PATH];
> int n;
> char *szFilePart;
>
> n=GetFullPathName(szFile,sizeof buf,buf,&szFilePart);
> assert(n);
> assert(n < sizeof buf);
>
> WIN32_FIND_DATA d;
>
> HANDLE h=FindFirstFile(buf,&d);
> assert(h != INVALID_HANDLE_VALUE);
> FindClose(h);
>
> if(szFilePart != buf+3) // "x:\" == 4
> {
> char b2[_MAX_PATH];
> assert(szFilePart > buf+3);
>
> szFilePart[-1]='\0';
> sub_canonical_filename(b2,buf);
>
> strcpy(szCanon,b2);
> strcat(szCanon,"/");
> strcat(szCanon,d.cFileName);
> }
> else
> {
> strcpy(szCanon,buf);
> szCanon[2]='/';
> szCanon[3]='\0';
> strcat(szCanon,d.cFileName);
> }
> }
>
> char *canonical_filename(const char *szFile)
> {
> char buf[_MAX_PATH];
>
> sub_canonical_filename(buf,szFile);
> strlwr(buf);
> return strdup(buf);
> }
>
> void main(int argc,char **argv)
> {
> char *szFile=argv[1];
>
> printf("%s\n",canonical_filename(szFile));
> }
>
> --
> Ben Laurie Phone: +44 (181) 994 6435 Email:
> ben@algroup.co.uk
> Freelance Consultant and Fax: +44 (181) 994 6472
> Technical Director URL: http://www.algroup.co.uk/Apache-SSL
> A.L. Digital Ltd, Apache Group member (http://www.apache.org)
> London, England. Apache-SSL author
>