httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: [PATCH - Showstopper] 1.3.17-dev mod_userdir
Date Thu, 25 Jan 2001 18:50:17 GMT
I will take a look at it.  It shouldn't be a problem.

Brad

>>> wrowe@rowe-clan.net Thursday, January 25, 2001 11:10:55 AM >>>
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 */
 }
 



Mime
View raw message