5lider has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks I need help with a cgi script called LECHAT.cgi its a web based chat room I have the script up and running on unbuntu 14.0.1 with apache2 After the script is uploaded I need to go to my browser and browse to the ?=setup page which I then need to create a superuser info which it saves to a file on my server, my problem is when I try and create a superuser I get told that it's not created and I need to make sure the script is allowed to create folders and files which I believeit has the correct chmod of 755? I've tried 777 and others but to no avail Amy one used this script and can help me out? Thanks

Replies are listed 'Best First'.
Re: (OT) Perk script help
by MidLifeXis (Monsignor) on Nov 11, 2014 at 17:04 UTC

    I would guess (and that is all that it is) that the web server is running as a user ID that does not have permissions to write to wherever the cgi script wants to write.

    That being said, if the application cannot be configured to write to a location outside of the HTMLROOT, run, don't walk, away from the application and find something else that meets your needs.

    The web server, as a 'best practice' (take that as you will), should never be allowed to write to any location directly accessible from web-space (in your HTMLROOT). Allowing the web server to write to an area directly [update: perhaps this should be "publically"] available via web-space likely allows for hijacking of your web server and other security or reputation related attacks.

    Note that denying this avenue of attack does not make your server 'secure', it just removes one avenue of attack.

    --MidLifeXis

      ... Allowing the web server to write to an area directly available via web-space likely allows for hijacking of your web server and other security or reputation related attacks. ...

      And if the whole purpose is to allow uploads what then? Or update a database?

      There are such things as permissions, neither uploads nor a database need to be an attack vector

        The key part of that phrase is "directly available via web-space". Unsanitized uploads into your web space are a problem. Period. Whether that sanitization comes from an application taking out the nasty bits, requiring a human to vet them, or trusted users being the only people with access to the upload, they need to be sanitized.

        Let's take one simple application of your example: an open upload server that accepts image files and presents them directly to web space. Let's suppose that $anonymous_user finds this service. Let's also say that this $anonymous_user has a taste for images outside of the social norm, and even outside of legal boundaries. Let's now say that $anonymous_user uploads some of these images so that they can be shared with other users with the same tastes. The server owner is now in a position of helping to distribute these images. Lucky guy.

        You are correct when you say that neither uploads or databases need to be an attack vector. Making them directly accessible into public web-space, however, falls on the "is an attack vector" side of the line. Is your quibble with the missing "public" from my statement? [note: added to original]

        --MidLifeXis

Re: (OT) Perk script help
by GotToBTru (Prior) on Nov 11, 2014 at 15:36 UTC

    Looks like an Apache problem, not a perl problem.

    1 Peter 4:10
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: (OT) Perk script help
by karlgoethebier (Abbot) on Nov 11, 2014 at 21:29 UTC