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

Thank you for reading this and/or responding.

This works on the command line:

chmod(0755, './DIRECTORY');

but not from a perl cgi script. What permissions/user change is necessary for this to work?

Replies are listed 'Best First'.
Re: chmod for cgi
by FamousLongAgo (Friar) on Dec 13, 2002 at 17:27 UTC
    The specific answer is that the CGI script is likely to be running with reduced privileges ( on a Unix system, this is commonly a user like "nobody" ), and from the command line, the script is running as yourself. Try setting the ownership of the directory so it belongs to the web server process.

    The nag-nag answer is, you should think hard about what you're doing. Changing permissions, deleting files, and doing other such things from a CGI script opens you up to a world of possible hacks. Be careful! Consider a cron job instead, or some other indirect method.

[reply]
Re: chmod for cgi
by VSarkiss (Monsignor) on Dec 13, 2002 at 17:31 UTC

    Well, chmod works in CGI scripts the same as anyplace else. There are complications in some flavors of *nix (e.g., ACLs in HP-UX), but basically, the process calling chmod needs to be the same owner as the target directory. The issue is not how chmod works; what usually trips up attempts like this is one of two things:

    1. The directory the CGI is executing in is not the same as the one where you're executing it from command line (thus, '.' is different).
    2. The user under which the CGI is executing is not the same as the one executing it from the command line.

    Figure out these two and you will probably fix the problem. If not, there may be deeper issues. In that case, post another question.

[reply]
[d/l]
[select]
Re: chmod for cgi
by Mr. Muskrat (Canon) on Dec 13, 2002 at 17:22 UTC

    I would recommend using the full path instead of this.

    Based on the "best" code from perlfunc:

    $mode = 0644; # ensures that the mode is in octal
chmod $mode, './DIRECTORY';

    [download]

[reply]
[d/l]
Re: chmod for cgi
by terrencebrown (Acolyte) on Dec 13, 2002 at 21:49 UTC

    Thank you all for your help.

    The answer lied in the owner of the file. When DIRECTORY was changed in Linux:

    chown -v apache DIRECTORY

    all went well. However, what kind of security risk is it to have directories owned by apache?

[reply]
[d/l]
      Hi Terrence,
      The issue is not so much directories being owned by apache as it is system level commands being executed by CGI scripts.

      If for instance directory was set to a variable and you did not check to make sure directory only contained valid data (or as most people say now make sure the data is not tainted) then it would be possible for people to try to inject other unsolicited behavior into your commands, such as adding additional directories. If you where doing system or exec this would be worse as they could actually add additional commands to be executed.

      The main issue here is that cgi scripts can be called by a user and any thing that a user passes to your scripts canot be trusted without validation. The best thing you can do is to remember that and always hardcode variable results, set them equal to system variables, and/or taint check any user data for things that shouldn't be there.

      This is just a short rant and I can provide much more of it if wanted.

      Dave -- Saving the world one node at a time

[reply]
Re: chmod for cgi
by terrencebrown (Acolyte) on Dec 13, 2002 at 23:01 UTC

    Thank you for your insight.

    The original intent was:

    chmod(0755, './STATES');
open(SAVEDSTATE,">$STATE_DIR/$session_key");
save_parameters(SAVEDSTATE);
close SAVEDSTATE;
chmod(0000, './STATES');

    [download]

    I think this is a little jicky and will switch to saving state to a MySQL database.

[reply]
[d/l]

Back to Seekers of Perl Wisdom