Home Dashboard Directory Help
Search

Accessing UNC vs mapped drive in Run as admin mode is different by TS_Prasanna


Status: 

Closed
 as By Design Help for as By Design


3
0
Sign in
to vote
Type: Bug
ID: 569696
Opened: 6/22/2010 9:41:35 AM
Access Restriction: Public
1
Workaround(s)
view
2
User(s) can reproduce this bug

Description

I am trying to access some files on share. But instead of accessing the share directory i have mapped the drive to share (say z:\). Now when UAC is on (windows 7) and i try to access the z:\ it works fine, but when i try to access the code with a process that has been started with "run as administrator" option, i am not able to access the "z:\" drive.

Whats more confusing is that i have put try-catch for DirectoryInfo.GetAccessControl method with catch block for UnauthorizedAccessException & SystemException.

So when i try to access the "z:\" the exception is caught in SystemException & the actual exception type is System.InvalidOperationException and message is "Method failed with unexpected error code 3". shouldn't the exception thrown from inside the "GetAccessControl" method be UnauthorizedException?

Not allowing to access a "z:\" drive when "run as admin" though the share (accessed as UNC path) is accesible, is this an issue or feature?

BTW, i am also not able to access the z:\ on windows explorer if i start the windows explorer with "run as admin" option.
Details
Sign in to post a comment.
Posted by Randy in Marin on 2/13/2014 at 10:58 AM
Seeing the same thing on 2012 R2. Accessing a UNC when elevated is safe, but a mapped drive is not? I don't understand.

In powershell I just figured out how to re-start a non-elevated script to force it to run elevated. (The script is meant to be simple and handle all the details of a SQL Server install.) I had to convert the path to a UNC (using Get-PSDrive) before doing re-running the script. Now I'm trying to figure out how to do this in a batch. I have a batch file on a share that I can't run as an admin because once elevated, there is no mapped drive to get the batch file. I really do want to run the file; otherwise, I would not have right-clicked it and run it as an admin. I don't want to copy it locally or use a UNC path.

I feel abused, not safer. A hacker won't be stopped by this. I'm working on this instead of something else important.
Posted by Robert Heinig II on 2/28/2011 at 6:10 AM
Yes, this is by design.

However, two or three tiny details should be made clear to others reading this thread, as the design's behaviour is surprising even having understood its goals and methods:
* "net use" in the admin cmd lists the drives as unavailable, a dir returns "cannot find the path".
* Re-mapping in an elevated explorer will not work on 7/R2 if the "Launch folder windows in a separate process" option is on (regrettably still a recommendable option).
* Persistently mapping the drive in an admin cmd will throw errors upon the next login.
* (7/R2- not tested under Vista) Run any app with a standard open dialog as an admin. The mapped drives will not work, as by design, if used e.g. via a recently-opened-project or -file list. But using the open dialog to just navigate to the drive then cancel will - surprise - simply activate the missing drive for this session and any other run-as-admin programs started afterwards, without going through the whole re-map hassle. Inconsistent behaviour.
* In Vista, an elevated prompt or shell will both launch elevated child processes, while in 7/R2 the prompt will and the shell will not. Simply edit a Report Server configuration file from an elevated explorer? Gotcha! OK, this is still by design, as the explorer I asked the OS to start elevated isn't actually elevated.

Clearly, this design is misleading and not conforming to either http://en.wikipedia.org/wiki/DWIM or http://en.wikipedia.org/wiki/KISS_principle .
Posted by TS_Prasanna on 7/2/2010 at 7:48 PM
Thanks Greg.
Posted by Microsoft on 7/2/2010 at 3:09 PM
Hi,

Thanks for reporting this. This is a really tricky issue. The system actually works as expected, let us look into this in detail and understand why:
There are two separate issues here:
1) The fact that the network drive cannot be accessed.
2) The kind of exception thrown.
Let’s treat them separately:

** 1 **

This is a Windows issue and is not directly related to .NET.
However, the behaviour makes good sense and is likely by design. The bug does not describe the scenario very exactly, so I try to guess and fill the gaps:
Say, user U is member of admin group on machine B. We create a share D on machine A and allow U to access the share. Now U can access D from B both - directly (\\A\D), and when it is mapped as a local drive.
Now start an elevated Explorer session on B. This does not run as U, but instead it runs as B\Administrator. So this session cannot access the mapped drive. But the network service still runs as U, as it was not restarted and the share is still accessible.

** 2 **

Exceptions thrown.
While this may be a little confusing, we cannot change this behaviour because it may break applications that rely on the existing error logic.
In addition, the exceptions we throw reflect the behaviour of Windows security system correctly. The mentioned exception originates from System.Security.AccessControl.NativeObjectSecurity. This class calls Win32.GetSecurityInfo on the file system (directory) resource and throws exceptions when an error is returned. The error code 3 that you mention stands for ERROR_PATH_NOT_FOUND (see WinError.h). According to MSDN documentation for DirectorySecurity.GetAccessControl, a SystemException is thrown when the directory is not found, which is exactly what is reported to us by Windows. This makes sense: if there are no permissions, the system should not "admit" to the user whether the directory exists, but the user has no permissions to it, or whether the directory does not exist as all. The system simply does not "see" it.

In summary, although this behaviour seems confusing at first, the system work correctly.

I hope this helps,

Greg
(Software Engineer of the .NET Base Class Libraries Team)

Posted by David A Nelson on 6/23/2010 at 3:20 PM
You need to map the drive for the admin user. The easiest way to do that would be to run Windows Explorer as admin and then map the drive.
Posted by TS_Prasanna on 6/22/2010 at 7:24 PM
@CommonGenius.com : On machine B (where the share folder is) i have given access rights to a domain user who is admin on machine A. Is there any thing else that i need to do?
Posted by Microsoft on 6/22/2010 at 7:01 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Posted by David A Nelson on 6/22/2010 at 12:50 PM
Mapped drives are user-specific; if you map the drive for your admin user, it will work.
Sign in to post a workaround.
Posted by Pallavi_Dhepe on 6/23/2010 at 12:24 PM
Hi

e.g. User is having mapped “z:” drive to “\\MachineName\FolderName” then
User needs to re-map same drive in elevated permissions user account.
For this, open an administrative command prompt [Go to “%windir%\system32\cmd.exe”, right click -> Run as an administrator]
Use the “Net Use” command to re-map the drive under elevated permissions.

e.g. net use z: “\\MachineName\FolderName”

More information of Net Use command you can find here: http://www.cezeo.com/tips-and-tricks/net-use-command/

Theory behind this workaround:

Running application as an Administrator does not change what user you run as. It just authorizes the application to have administrative access to the system.
Every user account has two possible tokens with different access rights to certain parts of the system. When you log in, you log in with the "limited" token. Drives are mapped under this token. When you launch an application "as administrator", i.e. right click -> run as Administrator, you are then running that application with the "elevated token".
Hence drives are needed to be re-mapped with “elevated token” again to make them visible to those applications which are accessing mapped drives and we are launching those applications “run as an administrator”

Please find more information on below link which Ranjee has provided:
http://www.vistaheads.com/forums/microsoft-public-windows-vista-general/125180-run-administrator-loses-access-mapped-drives.html