> 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
