Windows permission differences between spawning from Explorer and from cmd.exe

Question

I have noticed a strange behavior running a setup on Windows 10 that I can't understand. The setup creates a directory structure and, at a certain point, it renames one of the subdirectories it has created. What happened is explained below:

1. When I right-clicked the setup.exe in the Windows Explorer and selected "Run as administrator", the setup eventually failed because of a bad permission issue when trying to rename the subdirectory.

2. When I right-clicked on cmd.exe, run it as administrator and spawned the setup.exe from the command line, the setup completed successfully.

What was going on here? What's the difference between spawning an application from the Windows Explorer as administrator and spawning it from cmd.exe as administrator?

Thank you.

EDIT

• The root directory created by the setup is c:\personal. The initial subdirectory's path is: c:\personal\platform\db, and the renamed subdirectory should be: c:\personal\platform\database

• The user account running the setup belongs to the Administrators group and the setup process owner was this user in both cases.

Answer 1

Windows Administrator Accounts have a wide range of permissions in windows; However, they are still limited in what they can do. As an example, a Windows Admin Account lacks the permissions necessary to modify the files in the System 32 folder so long as they are owned by Trusted Installer. The admin does have permission to take ownership of the files, which THEN grants them the permission to modify the files, but cannot do so without having the ownership of the file.

On the other hand, when you launch an Administrator Command Prompt, the commands or services started from within that instance of cmd.exe are not run with Windows Administrator privileges. Instead, they are run with System privileges (note that the admin command prompt starts in the System 32 folder by default). System privileges are very similar to Admin privileges, with the main differences being that system permissions bypass some restrictions. In another thread it is stated:

One practical difference is that, if the computer is joined to a domain, processes running as SYSTEM can access domain servers in the context of the computer's domain account. Processes running as Administrator have no access to domain computers unless the password happens to match or alternative credentials are explicitly provided.

It is important to note that System isn’t an account that you can log onto though, it is just a set of permission or an abstracted idea of the Operating System being a user.

Answer 2

I think it's about "Start in" parameter. Probably setup is using relative paths and when you start setup file by double clicking on it "Start in" parameter is the path of setup file. But if you run that setup file from cmd "Start in" parameter is different than the path of setup file.

Answer 3

This is how I analyze the case you describe.

Windows Explorer is strangely programmed, in the sense that there is always only one explorer.exe instance, even if several Explorer windows are opened, and it is started during logon as a standard user, even if the login account is that of an administrator. This means that Explorer never runs in elevated mode, and that any process started via Explorer inherits this running mode. If the started process wants to acquire administrator permissions, it must demand elevation, thus requiring user approval (if UAC is enabled).

On the other hand, if a process is started from an elevated cmd.exe, it inherits this running mode, so it does not need to request elevation (and if it does then this is immediately "granted" with no UAC prompt).

Now, I have started in the past installation programs from Explorer so many times, and they always requested elevation and worked without fault. To be sure of the facts, I started an elevated cmd.exe as Admin both from the command-line and from Explorer and compared their permissions using Process Explorer. All permissions for both cases were absolutely identical.

This means that if the installation program you used was correctly programmed, it would have had no problem. The inescapable conclusion is that it was badly and weirdly programmed. The fact that it found it necessary to rename its own folder, is already an indication of something really strange. My guess would be that it was created by one programmer, then was added-to by another programmer that didn't dare modify the original code and only appended more stuff to it.

I have tried to imagine what kind of error could cause such a problem, and I only found the following, which you can verify by watching the installation as it's working, using Process Explorer as the tool.

• The installation is not one process, meaning that the initial setup launched more than one process. Perhaps not all these processes requested elevation.

• That folder was deliberately created with permissions that precluded a non-administrator from modifying it, and the rename was attempted by an invoked rename process that wasn't elevated (it would have been elevated if it were launched from an already elevated process). You may verify this by right-click of the folder in Explorer, choosing Properties, and examining the Security tab.

• The rename was attempted by one non-elevated process while the folder was still opened by another elevated process, so couldn't be renamed.

These are not the only possibilities - there is an unlimited number of possible programming errors. The problem can only be fully understood by carefully observing the installation while it is working.