Re: [FC] Strange behaviour in Vista

[Dr. Georg Czedik-Eysenberg]

Dear Jan,

many thanks for the perfect explanation of this tricky Vista function.

The question is now:

Should a tool like File Commander better have a manifest (with "run as 
invoker") to ensure,
that we get informed when we try to modify a file without permission,
i.e. it sees and modifies files like the other (modern) programs do?

Or is it better, that it has no manifest and therefore sees and modifies 
files like legacy programs do?

Or is there some third possibilty (like being able to switch between 
these two modes)
or being warned, when VirtualStore is used ... ?

Kind regards, Georg

On Thu, 06 Nov 2008, Dr. Georg Czedik-Eysenberg wrote:
  
I found a very strange behaviour in Vista:

File Commander (started normally, not in admin mode) allows me to copy
files into "C:\Program Files" and also to create directories there,
but both are only seen then by File Commander, not by any other software
(like "cmd" or Windows Explorer).
Similar when I edit the contents of files there (using File Commander's
internal editor).

Can anybody else reproduce this effect?
    

You are encountering the "VirtualStore" feature of Vista:  When running an
executable, it will check if the resources contain a manifest that tells
the loader the required privilege level (run as invoker, run as administrator).

When the manifest specifies "run as administrator" then you'll get a UAC
prompt to request permission to run with admin privs and after that you are
free to write to "C:\Program Files".

When the manifest specifies "run as invoker" then you will run without admin
privs, and the program gets a permission error when it tries to open a file
for writing in the "C:\Program Files" area.

When you don't have a manifest though Vista assumes you must be some kind
of legacy program that doesn't know about the stricter permission enforcement
of Vista.  Instead of generating the permission error Vista will create
a shadow tree in your user directory, normally

    C:\Users\USERNAME\AppData\Local\VirtualStore\Program Files

When you open a file for writing in the C:\Program Files tree it will first
be copied to this VirtualStore and then opened there.  You are free to modify
any files in C:\Program Files this way, but you won't actually update the
real (protected) files.

Similarly when you read a file from "C:\Program Files" and don't have a manifest
then Vista will first try to open a file in the VirtualStore and only if it
doesn't exist open the real file (in read-only mode).  This way the caching
happens lazily only for files that actually get opened for update.

Things are even more convoluted when you are running 32-bit applications on
64-bit Vista (in addition to the VirtualStore there is also file-system and
registry redirection for specific trees).

Only slightly related is one other feature: If your program looks like it
might be an installer, then Vista will assume that you want to "run as
administrator" even when you don't have a manifest.  The heuristics for
"looks like an installer" are not fully documented, but include having any
of the substrings "setup", "install", "patch" or "update" in the filename.

So if you ever wonder why you cannot run patch.exe normally from a
cmd.exe prompt, that's why.  There is a policy for these heuristics that
you can disable in the policy editor.  It is enabled by default for
machines that have not been added to a domain (I guess with the assumption
that users in a domain are normally not supposed to install software
themselves).

It is all a very clever way to provide backwards compatibility while still
improving security.  It is a nightmare though to figure out what is really
happening on your machine.

Cheers,
-Jan

PS: There is more stuff, like the automatic application of compatibility "shims"
to applications to work around known compatibility problems, but this post
probably already contains much more than you wanted to know about Vista.


_______________________________________________
Fc mailing list
Fc@silk.apana.org.au
http://silk.apana.org.au/mailman/listinfo/fc
Bug Tracker: http://bugs.silk.apana.org.au/


  

_______________________________________________
Fc mailing list
Fc@silk.apana.org.au
http://silk.apana.org.au/mailman/listinfo/fc
Bug Tracker: http://bugs.silk.apana.org.au/