Simple Create New File

[telconstar99]

Hello,

This is my first attempt to create a new file in perl. I have this code sitting in my cgi-bin directory of my webserver:

#!/usr/bin/perl

use CGI ':standard';

print header();

open (COLOURS,">colours.txt");
print COLOURS "My favourite colour is red\n";
close COLOURS; 

However, when I run this with my browser I get an empty screen (which is what I would expect) but no file seems to be created. I'm assuming the file would be created in my cgi-bin directory. My path to perl is 100% correct. Any ideas?

[CyCo]

It runs as expected on Windows & Linux. Are you sure "colours.txt" was "NOT" created in your cgi-bin?

What output do you get when you run the code below?

#!/usr/bin/perl

use strict;
use Cwd 'realpath';
use CGI ':standard';
use CGI::Carp 'fatalsToBrowser';

my $file = 'cyco_colours.txt';

open  COLOURS, ">$file" or die $!; 
print COLOURS "My favourite colour is blue\n"; 
close COLOURS;

print header, "Full path to $file: ", realpath($file);

[telconstar99]

I appreciate such a fast response.

I'm positive it's not creating the file in the cgi-bin directory. I copy and pasted your code into a file called test.cgi and when I ran it I got this.

Software error:

Permission denied at /web/sites/www.domain.com/cgi-bin/test.cgi line 10.

For help, please send mail to the webmaster (webmaster@domain.com), giving this error message and the time and date of the error.

[CyCo]

OK, now we're getting somewhere. The error is very helpful in troubleshooting the problem, which is a permission issue. My guess is that your umask setting (configured on the server) is denying write access at the default level.

Add this line right after opening the file.

chmod 0666, $file;

If that doesn't do it, then we'll need to check your umask value and go from there.

[telconstar99]

Thanks for the reply CyCo. I added your line and still have the same problem. Just to double check my code now looks like this:

#!/usr/bin/perl

use strict;
use Cwd 'realpath';
use CGI ':standard';
use CGI::Carp 'fatalsToBrowser';

my $file = 'cyco_colours.txt';

open  COLOURS, ">$file" or die $!; 
chmod 0666, $file;
print COLOURS "My favourite colour is blue\n"; 
close COLOURS;

print header, "Full path to $file: ", realpath($file); 

What's the next debug step?

[CyCo]

Bummer!

What output do you get when you run this little snippet?

#!/usr/bin/perl

use CGI ':standard';
use CGI::Carp 'fatalsToBrowser';

print header, umask;

[telconstar99]

It outputted this:

18

What does that mean?

[telconstar99]

BUMP...Anybody know what this means? Google isn't helping much.

[yitzle]

Idea:
Change
open (COLOURS,">colours.txt");
to
open (COLOURS,">./colours.txt");

[telconstar99]

Nope that still doesn't work. Any ideas where the problem is? Might this be a server config error?

[CyCo]

After re-reading this thread, I believe the best way to get to the bottom of this is to contact your host and find out what restrictions they have configured for your site. If you are on a free host or some other type of restricted hosting plan, then you probably won't be allowed to do certain things.

[rocknbil]

There is one more thing to try. This is a nuts and bolts method, but it works for me.

Remember you are trying to write to the directory in which the script is being executed,

my $file = 'cyco_colours.txt';

You may not have permissions to write to that directory. Another possibility is that depending on the server configuration, if the current path is not in @INC it may be trying to write to wherever perl thinks you are at that moment - which may be #!/usr/bin/perl. You certainly won't be allowed to write a file there.

So begin by a) defining and using the full path to where you want to write, and b) making sure you have permissions to write to that location. In this scenario create a directory called data outside of your cgi-bin:

/web/sites/www.domain.com/data/

Chmod it to 666, if that doesn't work test chmod it to 777 just to see if it's a permissions issue.

Second I like to write my own error handlers to avoid code and module bloat, but that's just me. Note my change in the or, and the added error subroutine. One last note - the $! variable holds system errors, so if the error is permission denied you can see it immediately in the response via the error sub.

#!/usr/bin/perl

$file = '/web/sites/www.domain.com/data/cyco_colours.txt';
open COLOURS, ">$file" or &error("cannot write file $!");
print COLOURS "My favourite colour is blue\n";
close COLOURS;
print "content-type: text/html\n\n";
print "If you see this, $file was printed";

sub error {
my ($err);
$err = shift(@_);
print "content-type: text/html\n\n";
print "Here is your error, fix it: $err";
exit 0; ## to stop script immediately if you encounter an error
}

[JohnGH]

...
I have this code sitting in my cgi-bin directory of my webserver:

#!/usr/bin/perl
...
open (COLOURS,">colours.txt");
... 

However, when I run this with my browser
...
no file seems to be created. I'm assuming the file would be created in my cgi-bin directory.

This is *hopefully* because the webserver process doesn't have write access to the directory the script is running in (as your say - presumably your cgi-bin directory)

This is a ***GOOD*** thing.

Your cgi-bin directory should *NOT* be writable by the user that the webserver runs the scripts as, otherwise, when someone finds something exploitable in one of your scripts (yes, I said "when", not "if" - because these things happen!) it will be simple for them to use that to create their own script in your cgi-bin directory and then run it to do whatever they want on your server that the user that your webserver runs as has access to do.

Data files should either be created manually first
(e.g. use 'touch colours.txt' on Linux/Unix, or 'type nul > colours.txt' on windows or create an empty colours.txt locally and upload it if you don't have shell access)
and made so that the web process can write to them (if they need to be written to)
(on Linux/Unix this is chown [WEBSERVER_USER] colours.txt and/or chmod +w colours.txt)
(read http://www.linuxmanpages.com/man1/chown.1.php and http://www.linuxmanpages.com/man1/chmod.1.php )

Or... better still, they should preferrably be stored in another directory that the webserver process can read from/write to but not execute programs in.

(if someone could write to colours.txt they may be able to write code into that and run it too if it is executable (??[x]??[x]??[x] on Linux/Unix) - unless your webserver only runs scripts by extension (e.g. will run .cgi or .pl but not .txt) ( as per AddHandler cgi-script (whatever) and ExecCGI )

John

[JohnGH]

So begin by a) defining and using the full path to where you want to write, and b) making sure you have permissions to write to that location. In this scenario create a directory called data outside of your cgi-bin:

/web/sites/www.domain.com/data/

Chmod it to 666, if that doesn't work test chmod it to 777 just to see if it's a permissions issue.

Don't chmod dirs to 666 - dirs need to be executable to be used... try this:

$ mkdir test
$ chmod 666 test
$ touch test/file
touch: cannot touch `test/file': Permission denied
$ cd test
-bash: cd: test: Permission denied
$ chmod +x test
$ touch test/file
$ cd test/
$ pwd
/home/john/test
$ ls -la .
total 8
drwxrwxrwx   2 john john 4096 2006-11-27 14:21 .
drwxr-xr-x  10 john john 4096 2006-11-27 14:19 ..
-rw-r--r--   1 john john    0 2006-11-27 14:21 file

IHTH

Kind regards,

John

[yitzle]

I don't think that is wise.
You got +rwx or 777 for your directories
That means you are letting anyone do anything
Directories should be 711 or 755 (eXecute or Read + eXecute)
Don't give write permission on a directory.
Only on select files.