Under UAC, why can't I write a file as an impersonated user?

Question

I'm impersonating a user until Windows 2008 with UAC enabled. I'm trying to write some files to a temp directory. But even if a user has write access to a directory, when I impersonate that user, I'm unable to write to that directory (I get an Access Denied error). Apparently, this is due to UAC blocking me.

This is related to a post on a microsoft forum: http://forums.iis.net/t/1149793.aspx But that forum got no response other than a microsoft employee repeatedly asking the same question and being silent when he got the info he asked for.

I've been able to get around this by not impersonating while writing to the temp file, but I have a few questions:

1. Why does UAC not allow writing to files when impersonated?

2. Is there any place I can put temp files while impersonated?

3. Is there some better solution? What's the "right" way to handle this?

4. Is there a source of documentation for what all the restrictions are for UAC & impersonated users?

Answer 1

My guess is you are writing to the temp directory specified in %TEMP% or via GetTempPath. This is a process-wide environment variable, so it doesn't respect impersonation. A quick way to verify is to check the path you are writing to, to see if it is under the impersonated user's profile.

The following code should be able to retrieve the temp path for an impersonated user.

// Error checking removed for brevity.
// User profile must be loaded by this point,
// see LoadUserProfile/UnloadUserProfile
SHGetFolderPath(NULL, CSIDL_LOCAL_APPDATA, impersonationToken,
                SHGFP_TYPE_CURRENT,path);
StringCchCat(path, cchPath, "\Temp");

Answer 2

Vista introduced integrity levels in addition to the standard permissions. Perhaps the integrity level your application is running as is lower than that required to write to the location/file.

Windows comes with a built in tool "cacls.exe", but I suggest chml from http://www.minasi.com/apps/ which makes it easier to view & edit them. See also http://msdn.microsoft.com/en-us/library/bb625964.aspx for more information.

Answer 3

You should try process monitor from msft. This tool should give you more information about why this is failing.

Answer 4

I think NuSkooler's answer is probably correct. The documentation he links to (specifically, this page) gives the following while talking about the root folder:

By setting a mandatory label with a high integrity level that applies to child objects, but not to child containers, the default security for the root folder meets this policy. Standard users that run programs at the medium integrity level cannot modify files created by administrators in the root folder, even if the ACL grants users modify access. The root folder has an inheritable mandatory label at high integrity that is object inherit and that does not propagate to subfolders.

I don't know the specifics of your situation, but that sounds like the same thing you are running into - not being able to write to the folder even though there is an explicit allow entry in the ACL.

You should try using Process Explorer and Process Monitor to see what exactly is happening, but it definitely sounds like it could be the integrity levels.

Also, you should run icacls instead of just cacls; this will show you the integrity levels in the ACL.