Odd UAC elevation issue with mapped drives

[Andy Bates]

Have been struggling with this issue for a little while now and wondered if
anyone could shed any light on the issues I'm seeing. It should be stressed
that this is a relatively clean Vista install and UAC is operational.

I have a Native C++ VS 2005 MFC application I've developed. This works
perfectly on Windows XP and previous versions but I'm seeing some odd issues
when it's run under Vista (32 and 64-bit).

An application is installed to a mapped network drive (call it Z. There
is a folder on Z: lets call it FOLDER with sub-folders under it. The
installed application runs as the invoker and operates without issue
accessing files in the folder and sub-folders under it correctly.

Another application (same development environment) runs from Z:\FOLDER and
copies files to local hard drives. Now this is where things get interesting.

The application needs to copy files from Z:\FOLDER and the sub-folders to
the local C:\ drive.

The application requests escalated rights and starts correctly. When it
tries to copy files from the sub-folders of the mapped drive it fails to
find any files to copy. Explicitly calling ::CopyFile using the mapped drive
letter (i.e. Z fails.

However if CopyFile is called using a UNC rather than a drive letter it
works correctly. Calling WNetGetConnection on Z: returns a failure (haven't
checked result but assume drive not mapped). So the issue doesn't appear to
be a rights issue.

Looking at the result from ::GetModuleFilename for the executable in this
instance it returns the UNC of the mapped network drive and not the mapped
drive letter (i.e. Z.

Now when it attempts to copy files from Z:\FOLDER (where it was invoked) it
works correctly and the files are found and copied.

Why are files in Z:\FOLDER found but files in the sub-folder not found? I'm
assuming that Z:\FOLDER is treated as an alias and gets mapped to the UNC
but that Z:\FOLDER\SUBFOLDER doesn't...

The solution appears to amend the manifest to specify that the application
should execute as the requester but I'm intrigued to know why I was seeing
the issues that I saw and how they can be resolved without executing as the
requester. Calling ::GetModuleFilename with the manifest amended in this way
returns a Z:\ based filepath and not the UNC path for the executable!

TIA

- Andy

 

[Jimmy Brush]

Re: Odd UAC elevation issue with mapped drives

Hello,

Drive mappings are not shared between different logons. Because of the
internal implementation of UAC, elevated programs are considered to be
in a different "logon" than non-elevated programs, even though they are
operating on the same desktop in the same user profile.

This blog explains it pretty good:
http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx

It sounds like UAC is doing some sort of application compatibility
kajiggering to make running an elevated program on a mapped drive work,
possibly a shim to translate the program's folder into a UNC path, but
it's not translating the path you need.

You'll need some mechanism of getting at the UNC path and using it
instead, or re-mapping the mapped drive inside of an elevated program.

- JB