Re: [FC] Strange behaviour in Vista

[Dr. Georg Czedik-Eysenberg]

... there is just one small trap regarding external manifests, see 
http://blogs.msdn.com/vistacompatteam/archive/2006/11/13/manifest-and-the-fusion-cache.aspx
Therefore it is a good idea, to make both installations to new 
directories and don't start fcw.exe there before creating the manifest 
files.
Dear Jan!

Partially I had the same ideas as you had:
I installed the FC twice:
  *  Installation 1 worked in the legacy mode.
  *  Installation 2 worked in admin mode via a LNK file with "run as 
admin" setting.
      Furthermore it had an INI file with other colours
      And I also changed the EXE's icon resource to a differently 
coloured one (in order to see the difference also in the task bar).

But I was not fully satisfied with my solution, as I wanted 
installation 1 to wotk in normal user mode, not in legacy mode.

When I read your e-mail (MANY THANKS!!!), I tried to add a manifest to 
the EXE in installation one
It did change its behaviour, but strangely it behaved in the admin way 
although my manifest contained level="asInvoker".

*At the end I found a much better (simpler) solution (external 
manifests):*

Now I have in installation 1 a file "fcw.exe.manifest" with the 
following contents:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity version="1.0.0.0"
    processorArchitecture="X86"
    name="ExeName"
    type="win32"/>
<description>elevate execution level</description>
   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
      <security>
         <requestedPrivileges>
            <requestedExecutionLevel level="*asInvoker*" 
uiAccess="false"/>
         </requestedPrivileges>
      </security>
   </trustInfo>
</assembly>

And in installation 2 it has the following contents (and no need for a 
special LNK file any more):
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity version="1.0.0.0"
    processorArchitecture="X86"
    name="ExeName"
    type="win32"/>
<description>elevate execution level</description>
   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
      <security>
         <requestedPrivileges>
            <requestedExecutionLevel level="*requireAdministrator*" 
uiAccess="false"/>
         </requestedPrivileges>
      </security>
   </trustInfo>
</assembly>

Kind regards, Georg

Jan Dubois schrieb:

File Commander should have an "asInvoker" manifest.  That way it 
manipulates the normal filesystem.  You can still run it elevated by 
starting it from an elevated cmd.exe session, or invoking it with 
"Run As" from the context menu, or even have a separate shortcut with 
the "RunAs" setting set to Administrator.

 

You should be able to add the manifest yourself using a tool like 
mt.exe from the Windows SDK, or reshacker if you don't have the SDK 
installed.  This way you don't have to wait for Brian to make another 
release.

 

One thing I would like to see would be different color sets that FC 
would automatically choose based on whether it is running as admin or 
not (checking the actual process token to see if the process is 
elevated and not relying on whether the user is a member of the 
Administrators group).

 

You can kind of do this yourself too by having FC installed twice, 
configured with different color schemes, and then make corresponding 
shortcut icons that run one with normal privs and one as admin. The 
main annoyance is that changes to directory shortcuts are not 
automatically propagated to both instances.  On the other hand having 
separate command histories for normal and elevated instances is 
actually an advantage. Personally I like using a red background for 
shell windows that are running with admin privs to make it real 
obvious that I should be more careful about things... J

 

Cheers,

-Jan

 

 

 

*From:* [EMAIL PROTECTED] 
[EMAIL PROTECTED] *On Behalf Of *Dr. Georg 
Czedik-Eysenberg
*Sent:* Thursday, November 06, 2008 3:43 PM
*To:* File Commander mailing list
*Subject:* Re: [FC] Strange behaviour in Vista

 

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 <mailto: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/
  

------------------------------------------------------------------------

_______________________________________________
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/