Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Opening files to write in browser returns Permission denied

by Lady_Aleena (Curate)
on May 02, 2017 at 22:14 UTC ( #1189368=perlquestion: print w/replies, xml ) Need Help??
Lady_Aleena has asked for the wisdom of the Perl Monks concerning the following question:

Hello. I just recently noticed when I try to open a file for writing in a script running in my browser, permission denied is returned. So, is there a way to programatically tell my script running in my browser it is okay to write to that file? Also, how do I do it?

I've looked at open and nothing popped up at me say this is where permissions are granted. Even File::Slurp's write_file returned permission denied. I think this is weird because I can open files to be read in the browser without any issues with either open or File::Slurp's read_file.

In the mean time, I have set both files' permissions to 666.

Note: Please tell newbies to die to always include the $! at the end. If I had $! at the end of my die message, it would have cut at least 15 minutes of me traversing directories thinking the file did not exist. I felt like a doofus.

Edit per hippo: My OS is Debian jessie.

Update: Running the same script from my web host does not require me to set the permissions to 666. It writes to the file while it is 644.

No matter how hysterical I get, my problems are not time sensitive. So, relax, have a cookie, and a very nice day!
Lady Aleena

Replies are listed 'Best First'.
Re: Opening files to write in browser returns Permission denied
by huck (Vicar) on May 03, 2017 at 00:19 UTC

    a script running in my browser

    Do you mean a script running on your server as cgi called by the browser?

    Or are you talking about some java/javascript actuality running in the browser

    For as far as i know, perl doesnt run in a broswer

    In the first case i would first wonder what userid/group the cgi is running under. You may be trying to write somewhere that your userid has access to, but the web-server does not

    In the second case, i would kinda suggest you just give up. There is supposed to be a very restricted environment presented by the browser called "the sandbox" and most activity outside that is curtailed. A quick google search has again suggested that writing files under the browser is not easy, one suggested sending what you wanted to write back over tcpip to a server process/cgi that sends it back as a downloadable file the user can then accept.

      I am talking about a script, one called sitemap.pl, that opens in my browser and displays html content. At the end of the script, I have it write a list created in the script to a file. sitemap.pl, opened in the browser, can not write to sitemap.txt in the same directory as sitemap.pl unless the text file's permissions are set to 666.

      So, from what I am gathering here, I have to set write files to 666 so that the output from scripts running in the browser can write to them.

      No matter how hysterical I get, my problems are not time sensitive. So, relax, have a cookie, and a very nice day!
      Lady Aleena

        How do you open sitemap.pl in your browser?

        You may find it of interest to run this

        my $user = `whoami`; chomp $user; my $groups = `groups $user`; chomp $groups; print "<br>I am running as $user in groups $groups\n";
        I suspect that the user you get back is not what you expected. I also suspect it is the last 6 in 666 that is fixing your problem. You are setting up a file that anyone can write into. Knowing what groups you are in and the perl process is running you may be able to determine what groups you may have in common. Setting that file (or directory) to be a member of that common group may mean you dont need to let anyone write to that file, but limit it to only userids in that common group.

Re: Opening files to write in browser returns Permission denied
by hippo (Abbot) on May 02, 2017 at 22:35 UTC
    I've looked at open and nothing popped up at me say this is where permissions are granted.

    Filesystem permissions are governed by the operating system. As you don't say which O/S you are using it's a bit tricky to give specific advice. If using a Linux-like system see the TLDP entry.

    Try changing the path to be your scratch area - it is likely that the webserver process user has permissions to write there.

Re: Opening files to write in browser returns Permission denied
by stevieb (Abbot) on May 02, 2017 at 23:01 UTC
    "Please tell newbies to die to always include the $! at the end. If I had $! at the end of my die message, it would have cut at least 15 minutes of me traversing directories thinking the file did not exist."

    We do, all the time. It's also laid out in nearly every single example in the open documentation you linked to.

Re: Opening files to write in browser returns Permission denied
by marto (Bishop) on May 03, 2017 at 08:57 UTC

    "I've looked at open and..."

    "Please tell newbies to die to always include the $! at the end. If I had $! at the end of my die message, it would have cut at least 15 minutes of me traversing directories thinking the file did not exist."

    Not sure how you missed this, it's in the open documentation, all the examples and you have been told about using this before (e.g. Creating a random generator). Also, consider avoiding File::Slurp due to issues.

Re: Opening files to write in browser returns Permission denied
by scorpio17 (Abbot) on May 03, 2017 at 16:00 UTC

    You don't want a file with 666 permissions - that means it's world writable: anyone can modify it (very poor security). The first thing you need to do is figure out what user the web server is running as. I think the default user for apache on debian is www-data. If you're using apache, the main config file should be located here:
    /etc/apache2/apache2.conf
    Inside there should be something like this:

    User www-data Group www-data

    If it's something different (i.e., "nobody" or "apache" - just make a note of whatever it is).

    Your cgi script will be running on the server as that user (not as you), so that user needs write permission to the file you want it to create. Also - the containing directory must be writable by that user (have write and execute permission).

    So you need to do something like this on the server (don't type the inline comments):

    cd /path_of_your_choice_goes_here
    sudo mkdir webapp_output_files     # create directory to hold your files - name it whatever you like
    sudo chown root:www-data           # set user:group ownership - note that the group should be the same group that the webserver runs as
    sudo chmod 775                     # note: this gives group write permission
    

    Now any user belonging to the www-data group should be able to write files into that directory. Run your script and see if that works. Make sure your writing the file into the webapp_output_files directory (or whatever you chose to call it). The file create should have owner:group of www-data:www-data, and the permission bits should default to either 664 or 644, depending on your umask setting.

    I hope that helps. Good luck!

      Maybe this is overkill?
        Overkill? Well, having locks and ignition keys for our cars might be overkill, too, because a simple switch would suffice. Imagine: never again having a problem about forgotten or lost keys. The problem is that then anyone could drive away with your car, just as 666 allows anyone to write anything into your file…
Re: Opening files to write in browser returns Permission denied
by soonix (Monsignor) on May 03, 2017 at 11:35 UTC
    I often end my die messages with "...\n\t$!\n\t" - that is: Newline + Tab at the end. If the message does NOT end with a newline (but e.g. with a Tab), die adds file name and line number of the die statement.
Re: Opening files to write in browser returns Permission denied
by Marshall (Abbot) on May 02, 2017 at 23:19 UTC
    re: $! and die messages.
    I ran through some typical die examples in a not well named thread, Re^3: Trouble iterating through a hash. Anyway some folks may find the examples instructive about what "autodie" does as well as $! and the effect of adding or not a \n to the die message (controls line number information).

    I don't have a one size fits all "standard coding procedure". I do things one way when the program is for me or perhaps for another tech professional. I do things differently when the target user/audience has minimal tech skills. Anyway knowing what the basic options are is a good idea for folks who write the code.

Re: Opening files to write in browser returns Permission denied
by Anonymous Monk on May 03, 2017 at 15:27 UTC
    "Please tell newbies to die to always include the $! at the end."

    We always have. In fact, you were told this very thing in the past but you disregarded it.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1189368]
Approved by Marshall
help
Chatterbox?
[sierpinski]: thanks LanX that helps
[haukex]: the first index is always 0 - $#array gives you the last index in @array
[sierpinski]: gotcha, thanks
[LanX]: length = last index +1

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (16)
As of 2017-12-13 16:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What programming language do you hate the most?




















    Results (369 votes). Check out past polls.

    Notices?