Re: Opening files to write in browser returns Permission denied
by huck (Prior) 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.
| [reply] |
|
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
| [reply] |
|
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.
| [reply] [d/l] |
|
|
|
Re: Opening files to write in browser returns Permission denied
by hippo (Bishop) 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.
| [reply] |
Re: Opening files to write in browser returns Permission denied
by stevieb (Canon) 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.
| [reply] |
Re: Opening files to write in browser returns Permission denied
by marto (Cardinal) 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.
| [reply] |
Re: Opening files to write in browser returns Permission denied
by scorpio17 (Canon) 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!
| [reply] [d/l] |
|
| [reply] |
|
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…
| [reply] |
|
Re: Opening files to write in browser returns Permission denied
by soonix (Canon) 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. | [reply] [d/l] [select] |
Re: Opening files to write in browser returns Permission denied
by Marshall (Canon) 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. | [reply] |
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. | [reply] |