Standard user can't write to the root of C in Windows 7

The OS in question is Windows 7 Enterprise. I'm having an issue where a process running as a standard user has to be able to write files to the root of the C drive. By default, standard user accounts don't have permissions to write to the root of C. I set the correct permissions on the C drive to allow users to write files (for troubleshooting purposes I gave standard users full read/write). However, UAC still prevents a standard user from writing files. I disabled UAC (both by the slider bar and through gpedit) and standard user accounts still can't write to the root of C. I’m receiving error “0x80070522.” My administrator accounts can but that doesn't help me since the process doesn't run as an administrator. I understand that by design UAC doesn't permit standard users from writing to C but if I have UAC disabled why is this still an issue? It seems that disabling UAC via the methods described above just turns off alerting of UAC messages and doesn’t actually disable UAC. Is this accurate? Does anyone have suggestions that can help me out here?

[edit] I also tried to disable UAC through the registry and still no dice

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

Claymoore

Writes to the root of C:\ are virtualized. The files will be in C:\Users\%UserName%\AppData\Local\VirtualStore.

Vista virtualized writes to c:\Windows and C:\Program Files and Win7 added virtualizing the root of C:\. There is also registry key vritualization for apps that try to write to HKEY_LocalMachine instead of HKEY_CurrentUser. You can disable virtualization for an application using application compatibility shims, but that will disable both file and registry virtualization for that application.

Common file and registry virtualization issues in Windows Vista or in Windows 7

Paul Boz

In layman's speak what are my options?

Paul Boz

I followed the troubleshooting steps detailed here: Common file and registry virtualization issues in Windows Vista or in Windows 7 but all of the options either lead to escalating to a superuser account or changing the data storage location (to something other than root C). Both of those options aren't really solutions.

za3bour

Try the following,

1. Run Registry Editor (RegEdit) by typing regedit at command prompt or at startmenu->run

2. Locate following [COLOR=blue ! important][COLOR=blue ! important]registry [COLOR=blue ! important]key[/COLOR][/COLOR][/COLOR]
:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System

3. Locate the following REG_DWORD value:
EnableLUA

4. Set the value of EnableLUA to 0.
Now Exit from Registry Editor and Restart the computer.

This should disable UAC, I think this is the only solution because be design standard users are not allowed to write on C: because most viruses/worms would love to do so instead of finding a good solution to this microsoft decided to go the easy way.

Webmaster

Here's some more info about the issue: User Account Control Data Redirection though that doesn't provide a real solution either other than redeveloping the app.

If it's background app you might be able to run it as a service which should also disable the virtualization/data redirection (I have no idea if the tools for that work on Win7). But the Run as Admin option, which effectively disables redirection, might actually be safer than disabling UAC entirely depending on what the app does (i.e. if it doesn't allow the user the specify the output and create arbitrary files at arbitrary locations).

On a similar note, I just read somewhere this virtualization/data redirection thing is a temporary solution and will be removed in future versions of Windows.

it_consultant

There is nothing like remoting into someones PC and trying to edit the hosts file and being asked where to save the thing because it can't go in its normal spot.

Despite MS' best efforts, I still need to add everyone to the admins group even in Windows 7. You can lock the machine down with GPOs, a google search and nerve will be able to undo any of those policies if they REALLY want too.

Paul Boz

za3bour wrote: »

Try the following,

This should disable UAC, I think this is the only solution because be design standard users are not allowed to write on C: because most viruses/worms would love to do so instead of finding a good solution to this microsoft decided to go the easy way.

I said in the original post that I've tried to disable UAC in the registry.

Webmaster wrote: »

If it's background app you might be able to run it as a service which should also disable the virtualization/data redirection (I have no idea if the tools for that work on Win7). But the Run as Admin option, which effectively disables redirection, might actually be safer than disabling UAC entirely depending on what the app does (i.e. if it doesn't allow the user the specify the output and create arbitrary files at arbitrary locations).

We've effectively disabled / removed every local admin account for standard users. Standard users can't use "run-as" because they don't have another set of local admin creds to elevate with.

Asif Dasl

Paul Boz wrote: »

My administrator accounts can but that doesn't help me since the process doesn't run as an administrator.

Try using RunAsSpc, it allows you to run an application with elevated credentials without the need to enter your password every time like you do with the original RunAs command in Windows. And you can encrypt the administrator's password in to a file so it is secure.

Runas Password

za3bour

Paul Boz wrote: »

I said in the original post that I've tried to disable UAC in the registry.

You said that you used gpedit that's why I thought you didn't change it, anyway I'm sorry I couldn't help you should look in ms kb.

Claymoore

Download and install the Application Compatibility Toolkit
Launch Compatibility Administrator
Under Custom Databases, right click and create a new application fix
Give it a name and path to the executable
Skip the Compatibility Modes
Select the NoVirtualization shim in Compatibility Fixes
The matching information should be OK, but you can customize
Save the database
Install the database (right-click and install or use sdbinst and path to the db)
Run the app and you will write to the root of C:

Keep in mind that both reads and writes are virtualized. The application doesn't know that the file is at the root or in the virtual store, it just goes about its business. It's when we try to look for the file in Explorer that we run into problems, and Lotus Notes id files or a Citrix client that copies files to the root of C: are two common examples of files that seem to disappear. Vitrualization fixes applications that were poorly written and try to write to places in the file system or registry where they shouldn't. If virtualization weren't working, the write would fail and the program would generate an error. Prior to virtualization, the only solution was to grant elevated privileges such as Power User or Administrator, or to start opening up ACLs on subfolders. If you open up the ACL on the root of C: and do not disable inheritance, you have effectively opened up the entire drive.

@Webmaster - If you try to run the application as a service you will have problems with Session 0 isolation in Win7. The service will run in session 0 while the user is in session 1, and the user will not be able to interact with the service to see any prompts or message boxes. You can fix that with the SessionShim shim or by enabling the Interactive Services Detection Service on the workstation.

This has nothing to do with elevated privileges an whether or not the application was launched with elevated rights, it's an application compatibility issue. If the user has rights they could create a new txt file at the root of C: by right-clicking and choosing New Text file. An application that tries to write C: would have the write virtualized and the file would be placed in the VirtualStore in the user profile.

Webmaster

Thanks for clearing that up about the run as service Claymoore.

Paul Boz wrote:

I understand that by design UAC doesn't permit standard users from writing to C but if I have UAC disabled why is this still an issue?

Disabling UAC entirely also effectively disables the option "User Account Control: Virtualize file and registry write failures to per-user location".

Enabled. (Default) Application write failures are redirected at run time to defined user locations for both the file system and registry.

Disabled. Applications that write data to protected locations fail.

So without NoVirtualization (as Claymoore described above) it's either redirect (UAC on) or fail (UAC off, or UAC on and the above gpo disabled) instead either redirect or place in the specified location.

Claymoore

Webmaster wrote: »

Thanks for clearing that up about the run as service Claymoore.

You're welcome. We see issues with this all the time during our compatibility assessments. I have never tried to use the shim to fix them, I use the service instead because we usually see several issues at each client. Just about every AV and VPN software has an interactive service, but even the Lotus Notes client has an interactive service that cleans up the user profiles. Why create and distribute multiple shim databases when I can enable one service?

wheez

Would XP Mode be an option, or do you really need to get it working in Windows 7?

Paul Boz

The objective is to get everything running smoothly in Windows 7. There's lots of great updates in here that I will follow-up on when I have some more time later. Thank you all very much. This place continues to be the best resource for the dumbest and most @#$$'d up questions.

Mojo_666

Not sure if your issue is resolved but you should use these tools to see what is actually going on then make the appropriate changes.

Process Monitor

Process Explorer

Paul Boz

I'm going to experiment with using shims tomorrow. My only concern is whether or not it will be one-way redirection. It does me no good to use a shim if the data is written to a different location and some aspect of the app tries to snatch that data back from c:\ and there isn't a way to pull it from where it was written with the shim. This is why we do the testing

dynamik

phoeneous wrote: »

Old program?

Sounds like it's time for process explorer!