You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/05/14 22:18:10 UTC

ftp glob/limits?

What would folks think about changing

    if (ap_strchr_c(arg, '*') != NULL) {
        /* Prevent DOS attacks, only allow one segment to have a wildcard */
        int found = 0;           /* The number of segments with a wildcard */

to permit multiple wildcards, but to restrict the number of matches
returned (configurable with a directive, of course)?

Over a small pattern space, uploads/*/* is often very useful.

What would be the sane default?  1,000 entries?

Re: ftp glob/limits?

Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Mon, 14 May 2007, William A. Rowe, Jr. wrote:

> What would folks think about changing
>
>    if (ap_strchr_c(arg, '*') != NULL) {
>        /* Prevent DOS attacks, only allow one segment to have a wildcard */
>        int found = 0;           /* The number of segments with a wildcard */
>
> to permit multiple wildcards, but to restrict the number of matches
> returned (configurable with a directive, of course)?
>
> Over a small pattern space, uploads/*/* is often very useful.
>
> What would be the sane default?  1,000 entries?

For anonftp usage I would prefer the restrictive behaviour, it's good 
enough for most users and most decent ftpd's already does it that way.

For example, you can find this in ls.c in vsftpd:
----------8<----------
    * Note that pattern matching is only supported within the last path
    * component. For example, searching for /a/b/? will work, but searching
    * for /a/?/c will not.
----------8<----------

which is a sane behaviour for a public server in my world.

For non-anonftp usage limiting the number of matches might be OK, if 
the thing stops recursion when hitting the limit and not just limit 
the reply send to the client ;)

So my vote would be "default to restrictive, a more relaxed behaviour 
must be explicitly configured".


/Nikke
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  A "bird in hand" makes brushing your teeth difficult.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: ftp glob/limits?

Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 14, 2007, at 4:18 PM, William A. Rowe, Jr. wrote:

> What would folks think about changing
>
>     if (ap_strchr_c(arg, '*') != NULL) {
>         /* Prevent DOS attacks, only allow one segment to have a  
> wildcard */
>         int found = 0;           /* The number of segments with a  
> wildcard */
>
> to permit multiple wildcards, but to restrict the number of matches
> returned (configurable with a directive, of course)?
>
> Over a small pattern space, uploads/*/* is often very useful.
>
> What would be the sane default?  1,000 entries?
>

In my mind, that's the problem. If you allow multiple wildcards
then you shouldn't limit the returned entries, because how
does the client have any idea that you've done so...
In other words, how does it know that foo.java doesn't
exist because it really doesn't exist or rather it
would have been the 1001st entry :)