From: "Brad Nicholes" <BNICHOLES@novell.com>
Sent: Thursday, January 25, 2001 11:12 AM
> It appears that mod_autoindex is having a problem with absolute paths that do not
> start with a / (sys:path vs sys:/path). I think this is a minor issue and can wait
> for the next bug fix release. I'm OK with the userdir patch as it is proposed.
I think the point of waiting (and our RM has proved most patient!) is that I don't
know how frequently we plan on bugfix cycles on the 1.3.x tree. It was an 8 month
span last year between 1.3.12 and 1.3.14, you could be looking at a year, or never ;-/
So...
I believe this patch below could be the end-all to this tangled issue. I need Brian's,
your's, our RM's, and my own +1 to proceed.
The patch below -removes- this question from mod_userdir, were it never belonged, and
elevates it to the ap_is_url() function. That function, on colon delimited file systems
(including Mac OS-pre-X) could do wonders for us. Or it could break us entirely.
I'm carefully reviewing this crack at things. I'd like to know why the sys:path isn't
accepted on Netware, the patch below may solve that as well. For security however, you
really ought to force all :/'s to :'s or :'s to :/'s, to assure the security parser
doesn't suffer from the user's discrepancies. ap_os_canonical_filename should be giving
us one and only one form of a name from many possible ways they user could key it.
I'm not so concerned about machine/sys: vs. sys: as I am about sys:foo vs. sys:/foo.
Is is realistic that we could have such a patch early this afternoon?
Bill
Index: modules/standard/mod_userdir.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/modules/standard/mod_userdir.c,v
retrieving revision 1.44
diff -u -r1.44 mod_userdir.c
--- modules/standard/mod_userdir.c 2001/01/15 17:05:51 1.44
+++ modules/standard/mod_userdir.c 2001/01/25 17:59:56
@@ -170,6 +170,15 @@
* the string to the userdir string.
*/
s_cfg->userdir = ap_pstrdup(cmd->pool, arg);
+#if defined(WIN32) || defined(OS2) || defined(NETWARE)
+ /* This is an incomplete path, so we cannot canonicalize it yet.
+ * but any backslashes will confuse the parser, later, so simply
+ * change them to slash form.
+ */
+ arg = s_cfg->userdir;
+ while (arg = strchr(arg, '\\'))
+ *(arg++) = '/';
+#endif
return NULL;
}
/*
@@ -261,22 +270,9 @@
if (strchr(userdir, '*'))
x = ap_getword(r->pool, &userdir, '*');
- if (userdir[0] == '\0' || ap_os_is_path_absolute(userdir)) {
+ if (userdir[0] == '\0' || userdir[0] == '/') {
if (x) {
-#ifdef HAVE_DRIVE_LETTERS
- /*
- * Crummy hack. Need to figure out whether we have been
- * redirected to a URL or to a file on some drive. Since I
- * know of no protocols that are a single letter, if the : is
- * the second character, I will assume a file was specified
- *
- * Still no good for NETWARE, since : is embedded (sys:/home)
- */
- if (strchr(x + 2, ':'))
-#else
- if (strchr(x, ':'))
-#endif /* def HAVE_DRIVE_LETTERS */
- {
+ if (ap_is_url(x)) {
redirect = ap_pstrcat(r->pool, x, w, userdir, dname, NULL);
ap_table_setn(r->headers_out, "Location", redirect);
return REDIRECT;
@@ -287,7 +283,7 @@
else
filename = ap_pstrcat(r->pool, userdir, "/", w, NULL);
}
- else if (strchr(userdir, ':')) {
+ else if (ap_is_url(userdir)) {
redirect = ap_pstrcat(r->pool, userdir, "/", w, dname, NULL);
ap_table_setn(r->headers_out, "Location", redirect);
return REDIRECT;
@@ -296,7 +292,7 @@
#if defined(WIN32) || defined(NETWARE)
/* Need to figure out home dirs on NT and NetWare */
return DECLINED;
-#else /* WIN32 & NetWare */
+#else /* !(WIN32 || NETWARE) */
struct passwd *pw;
if ((pw = getpwnam(w))) {
#ifdef OS2
Index: main/util.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/util.c,v
retrieving revision 1.193
diff -u -r1.193 util.c
--- main/util.c 2001/01/15 17:05:05 1.193
+++ main/util.c 2001/01/25 17:59:59
@@ -1723,6 +1723,22 @@
}
}
+#if defined(HAVE_DRIVE_LETTERS) || defined(NETWARE)
+ /* Netware, OS2 and Win32 have an additional headache, that the file paths
+ * look like potential URI's. Therefore, these platforms further restrict
+ * this test to comply with RFC2396 3.2. Authority Component. The standard
+ * suggests this scheme applies for absolute references to globally unique
+ * and persistent entities. In that sense, a mailto: or news: URL doesn't
+ * constitute any persistent resource that Apache will 'redirect' into.
+ *
+ * This test alone may be insufficient based on the context, since the
+ * v://foo is a legitimate reference to the foo member in the root of v.
+ * However, we assume here that that is not what the user intended.
+ */
+ if (u[x] && (u[x + 1] != '/' || u[x + 2] != '/'))
+ return 0;
+#endif
+
return (x ? 1 : 0); /* If the first character is ':', it's broken, too */
}
|