None of the CGI apps (Perl and ASP) on my site can perform system commands
(dir, del, copy, etc.) for most users. I am running IIS 6.0 on Windows
Server 2003. I have an app pool set up for the virtual directories that need
this functionality. The identity for that pool is local system. Each user
and the local system user have read & execute on the scripts and full rights
to the data directories. IIS authentication is set to basic authentication.
The system32 ACLs have not been changed from the default. I also made sure
that local system is a member of IIS_WPG.

The CGI apps all work fine for anyone who is an administrator on the server
and have logged on locally to the server before. They don't work for anyone
else. For example, one of the PERL scripts performs a dir command to find
certain files in a directory so it can open and parse them, then display
details to the screen. For administrators they see data from all the files
(10 or so), but for anyone else that should have permission to see the data,
the dir command returns 0 files. Also one of the ASP scripts (using
PerlScript) allows users to create new data files, edit them, and delete
them. The users are able to create new files and edit them, but they can't
delete them. The del command can't find the file.

These scripts all worked fine under IIS 5.0 on Windows Server 2000. What is

Additional Information:

Windows is returning an error code 255 (ERROR_EA_LIST_INCONSISTENT) when
trying to perform a dir command.

Any ideas?

Hi Nate!


"Nate" <Nate@discussions.microsoft.com> schrieb im Newsbeitrag
news:9ACB07A2-6C66-4C3C-B8F5-324608B720A4@microsoft.com...

[quoted text, click to view]

Have you tried to change NTFS permissions on the cmd.EXE?
I think there's been a change in Win 2003.
Try to add execute perms for the user context, in which the sript
is running (read/execute).
But that might be a security risk.

Regards,

Ralf

Thanks for the response. The user context in which the script should be
running has permission to cmd.exe by default. I ended up adding another user
group to the permission list on Friday. It worked, but is not the most
secure solution. I suppose it will have to do. Thanks again.

-Nate


[quoted text, click to view]