Odd UAC elevation issue with mapped drives

A

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
 
J

Jimmy Brush

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top