IIS Server - perl reading local files

Author

perl reading local files

Peter

2004-01-24, 1:39 am

I have a simple login to for an administrator to change the
message on a page every week or so. I need get my perl
script to read the login file, and then write to the html
page where the message is displayed.

For some reason, no matter what the permission settings are
on the files in IIS, PERL is not allowed access to them. A
friend told me I have to add the Internet Guest Account,
and give it permissions to read and write to them in the
operating system, but that is not available in windows XP
with IIS5. How can I do that with XP? If I am given good
direction that will work for W2K I will even step back an
operating system.

thanks

David Wang [Msft]

2004-01-24, 1:39 am

On IIS, all requests from the web are executed in the context of some
Windows user on the web server. That is, if IIS launches PERL to execute a
script, PERL will be running as that Windows user, unless you configure
otherwise.

When it comes to file/resource access on Windows, there are two things you
must match up -- the Windows user executing the request must have the
necessary permissions as dictated by the resource's ACL. So, we're talking
about:
1. What Windows user is your request running as
2. What are the ACLs on the resource in question

By default, Anonymous requests run as the Internet Guest User
(IUSR_<machinename> ). IIS-Authenticated requests (via Basic, Integrated
Authentication, Kerberose, Digest, Passport, etc) run as that authenticated
Windows identity (or in Passport's case, an Windows user mapped to the
Passport ID). Your custom authentication scheme is likely not using real
Windows users, so from the perspective of user identity, it is essentially
the same as an Anonymous request (with some extra checking of the request's
cookies, etc).

This means that the files you want to allow PERL to write MUST be given
Write/Modify NTFS ACLs to the Anonymous user that you are using, by default
IUSR_<machinename>, but can be customized by you.

In general, it is dangerous to allow the IUSR anything other than Read
permissions to certain resources on your web server -- since if any user
(i.e. hacker) can write files to your webserver in a directory that can
later cause it to be executed, your server can be hacked. So, I would only
grant IUSR write permission to the page you need modified via remote login

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Peter" <ppostma9@juno.com> wrote in message
news:02d301c3d806$c3415cf0$a501280a@phx.gbl...
I have a simple login to for an administrator to change the
message on a page every week or so. I need get my perl
script to read the login file, and then write to the html
page where the message is displayed.

For some reason, no matter what the permission settings are
on the files in IIS, PERL is not allowed access to them. A
friend told me I have to add the Internet Guest Account,
and give it permissions to read and write to them in the
operating system, but that is not available in windows XP
with IIS5. How can I do that with XP? If I am given good
direction that will work for W2K I will even step back an
operating system.

thanks

=?Utf-8?B?UGV0ZXI=?=

2004-01-24, 1:40 am

Yes, thank you. That was a very concise explanation.

I had figured it was something like that, but your response made it much clearer.

There is one tip that I can give for hackers altering write accessible files that works very well for me.
The script makes two copies of the file. One is put in the public folder which all the links tie to, and the other is put out of the way with no where no links are given to it, and a encoded file name is used so no one will recognize they are the same.
When the page is loaded, my scripts compare the viewing file with the back-up version. If any changes have been made the viewing copy is overwritten with the backup. That way if someone tries to alter my web pages, they must realize that there are to co
pies and change both before they can be successful. As long as the backup does not have the same name as the viewing file they never seem to catch on and think they have failed in changing the file.

Peter