RE: FTP on IIS

> 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

I've just re-re-verified this.  I've checked all permissions - I've
logged in as Admin, and I have full control over the entire structure.
If I try to edit any file in the web directory (it doesn't happen in
other directories) then I get an "access denied" after the first UAC
saying I must be admin to perform the function, and the second UAC
saying a "file operation" is about to be exectuted.

This is the same as if I copy from a network source.  If I edit the file
in my projects directory, it works fine.  If I then copy the file from
my projects directory to my wwwroot\web directory, it works fine.  This
is a default installation - there has been no alteration of NTFS
permissions or other configuration options.  Note that it is a "bare"
installation with no bells and whistles.  

I totally acquiesce to your greater experience of IIS7 through the
betas, but I'm having a difficult time accepting that a default
configuration anomaly or some programming bug would manifest itself in
an actual security feature that makes both logical and applicable sense.
I guess it could happen (and if you are correct then it obviously has)
but it's kind of tough to accept.  That being said, there doesn't seem
to be a mechanism by which I can control this behavior, which doesn't
bode well for my theory.  I'll install another VM and see what happens,
and get back to you.


> 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.

I didn't know about that - so, no, it wasn't me making manual changes --
but, we'll see what happens in the new VM.  I'm really hoping to find
consistent behavior, as I think it's actually a cool idea...

t