[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnump3d-users] A few 2.7 Issues

From: koan
Subject: Re: [Gnump3d-users] A few 2.7 Issues
Date: Thu, 10 Nov 2005 11:42:39 -0500

*** 1.  You have no song cache created = infinite loop. ***

This must be the one. I have a 0 byte /var/cache/gnump3d/song.tags

On 11/10/05, Steve Kemp <address@hidden> wrote:
On Thu, Nov 10, 2005 at 09:01:54AM -0500, koan wrote:

>    My apologies if this is a duplicate, but after emailing you (steve)
>    directly several times, I haven't recieved any responses so I assume the
>    previous emails were caught by a spam filter or some such thing.

  Sorry, I saw your reminder mail and left it until I had more time.

  I've now looked at this and I cannot reproduce your problem.
However I'm pretty sure I know what the problem is ..

>    Further investigation revealed that even without the authentication at
>    all, it is possible to duplicate the issue if you simply open a browser
>    and go directly to the URL " http://zzzzzz/random/directory " where zzzz
>    is your host/root directory.

  This is not somethign I can reproduce.  However I can see there are
cases where this fails.

  There is a (deliberate) infinite loop in the processing of the
random directory code which looks like this:

    while( we don't have a directory )
       1. pick a line from the song tags cache
       2. if it doesn't have a directory
       3. if the line isn't excluded.

       we have our directory

  So there are three places where this could fail:

    1.  You have no song cache created = infinite loop.

    2.  You have all your music beneath the root - with no
    subdirectories == Infinite loop.

    3.  All possible entries are excluded == inifinite loop.

  I guess the solution here is to have a counter and abort after
N attempts.  I'll code that and commit it shortly.

  If you have a setup where you believe none of those three things
apply then I'm off-base and we should investigate further.  But
I can't see anything obvious in the code which would fail apart
from those three issues...

>    I'm not sure about this next part, but it also appears this could be a
>    possible DoS situation: although the system usage wasn't much of a problem
>    for my box (Athlon XP 2500), the log file grew to over a GB in ajust a few
>    minutes and eventually filled the entire partition. I don't have a
>    separate /var/log partition ( yes shame on me! ) so filling the disk could
>    have made some nice nasties had I not noticed it right away. I'm not great
>    with perl, so I cant quite tell what safeguards you may/may not have in
>    place for this type of thing.

  This part makes little sense to me, without more investigation, so
I'll have to do that later.

>    Also, although I dont want to press the issue too much further after your
>    initial reply, I would think this helps justifiy my initial concerns about
>    printing this extra information in the cases of access control: had the
>    header not been printed I would have never discovered this issue.

  Right.  Noted.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]