-----Original Message-----
From: Thor (Hammer of God) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 23 January 2008 4:12 AM
To: Ken Schaefer; [email protected]
Subject: RE: FTP on IIS


> > > (like how you can't copy content to web
> > > source directories over the network, or how you can't directly
> > > edit web content in those directories).
> >
> > Can you elaborate on this please? There's nothing special about "web
> > source directories" (I assume you mean folders that store files that
> > are published via IIS 7.0 over HTTP)?
>
> You know, when I wrote that, I knew it wasn't as clear as it could have
> been. I will certainly elaborate:
>
> Indeed, I mean the directories where web content is stored on the file
> system, such as "c:\inetpub\wwwroot\YourStuffHere".
> By default, you can't copy files to these directories from any network
> source, "such as "copy networksource c:\inetpub\wwwroot\YourStuffHere"
> via cmd or UI.

I think there is something up with your configuration. I would check your NTFS 
permissions.

>  Nor can you edit content directly in these directories
> (like using notepad to edit and save a file) even if in as Admin -- the
> operation fails...  You have to edit content a directory you have access
> to (a local file) and then copy from local to the web directories.

No - that isn't true either.

> Note that this has been in the last couple of beta's I've been running
> -- if MSFT have changed this in the release, then obviously you'll see
> different behavior.  The reason for this makes total sense:  to stop an
> exploit from copying content from a network source to your web directory
> -- you'd have to work a good bit harder to do so now.  I've not really
> documented too much of this as we're still in beta...
>
> Is this not the behavior you've seen?  If not, what build are you on?

I haven't seen this behaviour, and I've been working with Longhorn since about 
build 5000 or so. I've been working on Professional IIS 7.0 (Wrox Press) for 
about 18 months now, and I've been presenting on IIS 7.0 since Tech.Ed 
Australia in 2005.  So, I've worked with quite a few builds :-)

I've just validated using both RC0 and RC1 builds (those are the only two IIS 
VMs I have on this laptop) that I can copy files from a network location (I 
just used the host machine as the source server) to c:\inetpub\wwwroot and that 
I can edit the iisstart.htm file using Notepad.exe

Now:
There /is/ an option to apply a certain sandboxing feature in IIS 7.0 that not 
many people know about. So I'll toss this in so we're still talking security :-)

Each worker process is injected with an additional SID specific to that app 
pool. The "user name" that the SID corresponds to is the name of the app pool. 
If you check c:\inetpub\temp\apppools and check the NTFS permissions on the 
config file that is generated when you start an app pool, you'll see the 
additional SID.

If you want, you can optionally choose to ACL your web content using that SID 
(i.e. remove Network Service, or whatever your app pool identity is, and using 
icacls.exe or similar to apply read permissions for that dynamic SID).

This makes it an option to host all your app pools using one account (network 
service) yet still sandbox each app pool from the content that every other app 
pool can access. Neat huh?

But this is a manual process, and shouldn't explain what you are seeing.

Cheers
Ken

Reply via email to