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

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


3
0
Sign in
to vote
ID 569696 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 6/22/2010 9:41:35 AM
Access Restriction Public

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.
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.