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 - Showstopper] 1.3.17-dev mod_userdir
Date Thu, 25 Jan 2001 19:04:19 GMT
From: "Bill Stoddard" <bill@wstoddard.com>
Sent: Thursday, January 25, 2001 12:39 PM


> I would really prefer to get 1.3.17 out w/o this patch.  We can roll a new
> release in a few weeks.

I want to get 1.3.17 patched and tarred today.  I can't parse your comment.
Do you object to the patch on it's merit, object on the potential for introducing
a problem, or do you object to the [potential] delay?

To the patch: mod_userdir today is broken on os2/win32 if the user isn't very, very
precise about what they type.  This patch assures that win32 accepts the directive

  UserDir "C:\WinNT\profiles\*\My Documents\My Website"

without complaint.  Today it doesn't, and mod_userdir on netware is unusable.

The patch reduces the ambiguity of the code.  The question; side effects?  I will
be done with my complete review in about an hour.  I eliminated the potential side
effects for unix and localized them to ':' containing file systems, only.  It's
probably the right patch for unix, but we can remove the #if defined(...) wrapper
_after_ we roll 1.3.17 to avoid introducing a new problem.

As for the other 'patch', normalizing sys:/foo vs. sys:foo, I'm waiting on a
response, but I won't be waiting all that long.  We can roll without it, and if it's
provided this afternoon, that patch will affect -only- netware.

Bill


> ----- Original Message -----
> From: William A. Rowe, Jr. <wrowe@rowe-clan.net>
> To: <new-httpd@apache.org>
> Sent: Thursday, January 25, 2001 1:10 PM
> Subject: Re: [PATCH - Showstopper] 1.3.17-dev mod_userdir
> 
> 
> > 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