Well, first of all this indicates you are probably not checking the returncode of your mkdir properly, otherwise you would at least see the (superficial) reason. The standard idiom (not just for mkdir but for almost all systemcalls) is:

mkdir($dir) || die "Could not create $dir: $!"

In case you don't have access to the web server logs, you might want to look at CGI::Carp, especially fatalsToBrowser. To give users of your CGI running into such an error a more pleasant experience, it's also often a good idea to wrap the CGI processing in an eval and write the real error to the log and present the user with some nice failure message.

What you will see is most likely "permission denied", and the cause is that the webserver is running as some user (for example "nobody"), the CGI programs get started as that same user, and he doesn't have the permission to create directories at the place you are trying to use.

So from here on I'll assume you are running on UNIX and this is the actual problem. If not, ignore the rest

If you just need a once per run temporary directory, you can probably create it in /tmp, preferrably using File::Temp since securily creating things in /tmp can be a bit tricky.

If you need some permanent working directory and want it in your homedirectory /home/user, you need to get a bit more tricky. Here is one way:

- As "user", create a directory /home/user/a and 
  chmod it to permissions 777
- Make a CGI script that when run creates a subdirectory
  /home/user/a/cgi_work with permissions 777 again
- As "user", move that directory from /home/user/a/cgi_work
  to /home/user/cgi_work
- As "user" remove the now empty directory /home/user/a
  (well, since it existed without protections for a bit of
  time, someone else can have snuck stuff into it in the
  mean time. Scream loudly to the admin and/or that person
  in that case)
- Make yet another CGI script that changes the 
  permissions of /home/user/cgi_work to something 
  sane again (probably 755).
- Make sure /home/user/cgi_work is empty 
  (otherwise repeat the scream ploy)
[download]

Now you will have a directory /home/user/cgi_work with proper permissions owned by the webserver user that you can use as persistent storage.

If however other people can also do CGI on this server, you should keep in mind that their programs will run as the webserver user too, so they will have full rights into this directory too.

In that scenario I consider that server badly set up. Each person should be running as a different user really, using something like suexec for apache.

My personal opinion is actually that not using something like suexec is always the wrong thing to do. CGI is one of the most likely vectors that allows a hacker access to your system, and if you run CGI as the webserver user, he directly gets control of the server (think of the fun the hacker can have with ptrace for example).

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.