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

Hello People, I am having troubles with a perl functionality build in our content management system. There is a script used to export data. Before you can do so, the script has to look for a set of directories within a certain directory on a remote share. this work fine called from both command line and through CGI. The server where the script runs correct is a old windows 2000 machine. It doesn't matter of you use Apache 1.3 or IIS5 to call it through CGI, both work fine. I am assembling a new server and want to use this script again. This is a windows 2003 server box, with IIS6 and Apache 2.0 installed. The script is still able to retrieve the collection of directories from the remote folder, but only if you run the script from command line. When I call the script through CGI I get the message "No such file or directory" returned in $!. I am sure this has something to do with security, but I am not sure where to start. I want to know what user account Perl is using when it is getting called from CGI, but $< $> $( and $) all return 0. I assume these variable only are filled on unix based machines. Can anybody push me into the right direction? Thx in advance!

Replies are listed 'Best First'.
Re: Find perls user account on windows
by BrowserUk (Patriarch) on Aug 01, 2008 at 12:31 UTC

      Thx! I'll try that one as well.

      I have somehting to shew in for an hour. Be back soon!

Re: Find perls user account on windows
by syphilis (Archbishop) on Aug 01, 2008 at 12:51 UTC
    "No such file or directory" returned in $!. I am sure this has something to do with security

    But that's a rather unusual message to be getting for a security-related problem. Normally, I would expect security-related messages to be along the lines of "Permission denied".

    "No such file or directory" usually means simply "no such file or directory", and can often indicate that the cwd is not what you expect it to be - especially where IIS is concerned. So ... if you don't make progress by looking at the user account, take a look at what the cwd is and see if that helps. (There's no guarantee that it will :-)

    Cheers,
    Rob
      But that's a rather unusual message to be getting for a security-related problem. Normally, I would expect security-related messages to be along the lines of "Permission denied"

      That's what I was thinking too, yet is has something to do with security. I found out when I set the user account IIS is using to system account, that suddenly access is granted to the remote share, and I can read it content, instead of getting "no such file...".

      Next thing is why things go wrong wrong woth impersonation, but that's for after the weekend.

      Cheers

Re: Find perls user account on windows
by ikegami (Patriarch) on Aug 01, 2008 at 12:11 UTC
    How about $ENV{USERNAME}?
      Tried that one by looping through the complete %ENV hash, but $ENV{USERNAME} does not exist, on both the new and the old server.
Re: Find perls user account on windows
by jethro (Monsignor) on Aug 01, 2008 at 12:21 UTC
    Shouldn't a process list on windows show which user runs apache and consequently the script? If that 'consequently' might not be the case, put in a sleep(20) into your script and look at it in the process list

    (UPDATED)

      Problem with apache on the new server is, it uses a fuzzy CGI wrapper that impersonates the actions perl does with the account that is logged in on the content management system. I am not very into impersonation, but I think it does not only matter to whom the process is impersonated, I 'heard/read' its more important to know who impersonates. I don't know what account is used for the impersonating. In IIS its easier for me to determine what account is used, and that's a good point indeed. I'll have a go at that one. Thx! Besides all, I am just beginning with perl. If my issue is a security issue (I can't really think of something else) I would of expect to get a different message returned in $!, other then "No such file or directory" that is. Is this normal perl behavior when it can't open a folder due to security issues?
Re: Find perls user account on windows
by Sagacity (Monk) on Aug 03, 2008 at 14:46 UTC

    Your quest to find out which account perl runs as on the Win2003 box can be answered by looking at the process as was suggested by jethro. Then, as you correctly have assumed, the account must have "system" privileges or at least have permission to access the directories in question, in order to run on the windows box. On winserver boxes starting with Server2000, the whole directory/file access mechanism was re-configured to run through the security protocols in order to control who can see and access what based on access groups and privileges/permissions. It's a MS Server2003 thing.

    You stated it yourself that when the script ran through the command line it all worked fine, and did so because you are logged in with an account that has high enough privileges to do so without question (Admin privileges, maybe?). But assigning "system" or "Admin" privileges is NOT the best solution as far as security goes. It would be better to first find the account being used (Use jethro's suggestion for that), go to the directories that need access (And, make sure you want to grant access to the script for this), and simply add the user account to the list of accounts that have permission to access the directory and all its sub-directories as needed. This way you can control the scope of the machine that is used by your script, and control the scope of the machine that is vulnerable as well.

    Good Luck!