%SystemRoot%\Temp access on Vista+ from the User account.

[GuruSR]

First off, there are 2 (typically) Temp folders in Windows:
The system folder: %SystemRoot%\Temp
The user folder: %temp%

Those two folders "were" being monitored by a piece of software I had written to remove bloat (on a constant schedule). The user (Admin) logged in would (pre-Vista) have no issues cleaning both up, but with the UAC present, this is no longer the case.

The issue I'm having is, how to "properly" gain access to the System Temp folder (above) without resorting to altering the access rights on it. The program runs in the user account (because it looks at the %temp% folder and other user based folders added as "junk" folders). Sadly one machine running a multitude of software is leaving cab files in the System Temp folder by the thousands and eating +60 gigabytes of space unless manually cleaned out (which should be what my software is to do, could do before the UAC).

I'm not totally convinced the SeDebugPrivilege permission will actually let me into that folder on all versions from Vista and upward. Has anyone delved into this? I do know SYSTEM has Full access to that folder, but if going to SYSTEM would work, I'd need an elegant way to do it, that won't break under any OS from here out. I actually have checks in the code for every version of Windows from well, the dinosaur age (well, 32 bit anyways) and these checks ensure the software does the same thing regardless of the OS (Windows 10 included). I didn't "break" any rules in writing the software, so I don't want to start now. Am hoping someone understands this enough and has some insight on how to accomplish this.

Thank you in advance!

[2kaud]

SeRestorePrivilege right will allow write access control to any file/folder irrespective of permissions. However, it shouldn't be granted to a user as it enables the holder to bypass file/folder permissions to all files/folders.

There are 4 environment variables involved here. There are TMP, TEMP for user and TMP, TEMP for System. To see the values set for these, from Control Panel, System, Advanced System Settings, Advanced, Environment Variables. Then see what TMP, TEMP are set to for user and System. From an administrator, the location pointed to for System TEMP/TMP can be changed to point to a folder to which you do have permission. This is what we do. We don't have a folder %SystemRoot%\Temp on our systems. We have it as c:\Temp

If changing the location for system TEMP/TMP is impractical then probably the way forward is to write a service (running under system) to access the required folder/files.

What are the permissions for %SystemRoot%\Temp ? Have you tried elevating the program to Run As Administrator?

[Arjay]

Is changing the temp file location an option? If so, then look at SHGetFolderPath in msdn. Use the CSIDL_COMMON_APPDATA flag to retrieve the root folder where you can read and write appdata.

As Windows versions have evolved, security has tightened up and programs have a restricted set of folders with right access. There are guidelines for classifying data and explaining which folders are accessible. Unfortunately, this info is hard to find. Try searching for "Windows application compatibility guidelines".

[GuruSR]

SeRestorePrivilege right will allow write access control to any file/folder irrespective of permissions. However, it shouldn't be granted to a user as it enables the holder to bypass file/folder permissions to all files/folders.

There are 4 environment variables involved here. There are TMP, TEMP for user and TMP, TEMP for System. To see the values set for these, from Control Panel, System, Advanced System Settings, Advanced, Environment Variables. Then see what TMP, TEMP are set to for user and System. From an administrator, the location pointed to for System TEMP/TMP can be changed to point to a folder to which you do have permission. This is what we do. We don't have a folder %SystemRoot%\Temp on our systems. We have it as c:\Temp

If changing the location for system TEMP/TMP is impractical then probably the way forward is to write a service (running under system) to access the required folder/files.

What are the permissions for %SystemRoot%\Temp ? Have you tried elevating the program to Run As Administrator?

The software itself could use the SeRestorePrivilege as a last resort, but I'd rather avoid it, though there is no real worry, I could easily have it request the permission and revoke it at the end of working with that folder. As for adding another service, I'm concerned about making the service just for relaying data and the overhead needed. I guess a simpler/safer method would be best, but if there wouldn't be any issue with using SeRestorePrivilege other than it's dangerous, I can't see it being abused, since the software itself is designed not to touch any hidden/system files temp or not.

Changing the location for the system Temp is not practical, as the software will be used on a variety of systems sometimes not in one location and to require each one to have that Temp moved, would be a headache. Running as an Admin, the program indeed does see the actual folder and it's contents just fine and is able to alter it. The owner is "SYSTEM" and others have next to no access. Each time you go into %SystemRoot%\Temp, you'll be asked for the Admin rights to enter it.

Is changing the temp file location an option? If so, then look at SHGetFolderPath in msdn. Use the CSIDL_COMMON_APPDATA flag to retrieve the root folder where you can read and write appdata.

As Windows versions have evolved, security has tightened up and programs have a restricted set of folders with right access. There are guidelines for classifying data and explaining which folders are accessible. Unfortunately, this info is hard to find. Try searching for "Windows application compatibility guidelines".

Actually, not sure you understand the question, the issue isn't with where that folder is (I know here it is HKLM\System\CurrentControlSet\Control\Session Manager\Environment\Temp), it's not the CSIDL_COMMON_APPDATA flag (for certain). The permissions of that folder has not really been altered (XP still had SYSTEM as an owner on one I looked at), but now the UAC is enforcing them on Vista+ systems. And to be certain, the compatibility guidelines is what I'm trying to follow, as the application most likely will continue to work on later versions of Windows as it has for years.

Now that I'm thinking of it, I'd rather avoid elevation of the software to Admin, just does not seem wise.

[Arjay]

The software itself could use the SeRestorePrivilege as a last resort, but I'd rather avoid it, though there is no real worry, I could easily have it request the permission and revoke it at the end of working with that folder. As for adding another service, I'm concerned about making the service just for relaying data and the overhead needed. I guess a simpler/safer method would be best, but if there wouldn't be any issue with using SeRestorePrivilege other than it's dangerous, I can't see it being abused, since the software itself is designed not to touch any hidden/system files temp or not.

Changing the location for the system Temp is not practical, as the software will be used on a variety of systems sometimes not in one location and to require each one to have that Temp moved, would be a headache. Running as an Admin, the program indeed does see the actual folder and it's contents just fine and is able to alter it. The owner is "SYSTEM" and others have next to no access. Each time you go into %SystemRoot%\Temp, you'll be asked for the Admin rights to enter it.



Actually, not sure you understand the question, the issue isn't with where that folder is (I know here it is HKLM\System\CurrentControlSet\Control\Session Manager\Environment\Temp), it's not the CSIDL_COMMON_APPDATA flag (for certain). The permissions of that folder has not really been altered (XP still had SYSTEM as an owner on one I looked at), but now the UAC is enforcing them on Vista+ systems. And to be certain, the compatibility guidelines is what I'm trying to follow, as the application most likely will continue to work on later versions of Windows as it has for years.

Now that I'm thinking of it, I'd rather avoid elevation of the software to Admin, just does not seem wise.

I am suggesting that you move the location of these files to a recommended location as specified by the app compat guidelines. Temp is no longer the recommended location and probably hasn't been since about Win2K/XP.

[GuruSR]

I am suggesting that you move the location of these files to a recommended location as specified by the app compat guidelines. Temp is no longer the recommended location and probably hasn't been since about Win2K/XP.

Actually, the TEMP that I'm speaking of is in use in Windows Vista, 7, 8.x and 10. It is used by services running in the SYSTEM account that require a temp folder whether or not a user is logged in, so yes, it is still being used. I'm not about to move a system folder, which breaks guidelines.

[Arjay]

Actually, the TEMP that I'm speaking of is in use in Windows Vista, 7, 8.x and 10. It is used by services running in the SYSTEM account that require a temp folder whether or not a user is logged in, so yes, it is still being used. I'm not about to move a system folder, which breaks guidelines.

You misunderstand. I am not suggesting you move the temp folder. I am suggesting that you follow the app compat guidelines and store your writable app data in the location they recommend. I believe the common_appdata will be writable, but double check the app compat guidelines to be sure. At any rate, the correct place is no longer temp (because if it were, your app would have access without elevation).

[2kaud]

You misunderstand. I am not suggesting you move the temp folder. I am suggesting that you follow the app compat guidelines and store your writable app data in the location they recommend. I believe the common_appdata will be writable, but double check the app compat guidelines to be sure. At any rate, the correct place is no longer temp (because if it were, your app would have access without elevation).

I think it's programs other than the OP's own that are writing data to the system temp folder - and the OP wants his program as a user to be able to delete stuff left in the system temp folder by other programs (installers etc). Prior to Vista, this was easy from a user program but since Vista isn't. The OP has said that he wants to avoid elevation to administrator, avoid using SeRestorePrivilege, avoid a service and not change the system temp location. ???

[Arjay]

I think it's programs other than the OP's own that are writing data to the system temp folder - and the OP wants his program as a user to be able to delete stuff left in the system temp folder by other programs (installers etc). Prior to Vista, this was easy from a user program but since Vista isn't. The OP has said that he wants to avoid elevation to administrator, avoid using SeRestorePrivilege, avoid a service and not change the system temp location. ???

Probably outting the code into a service is the best option. With a service, the service can be run under an account that has access permissions regardless of the logged in user. That being said, I get the part about wanting to avoid using a service.

Btw, some folks avoid services because they find them difficult to write (not saying this is the case here). What many folks don't know is a good starting point for a service is to start with the ATL Project and then choose the service (exe) option. After the project is built, just strip out the COM related code. You are left with a stub service that contains the registration code and registering the service is as easy as running the exe with the /Service switch.

[GuruSR]

Well, my reasoning for not using a service is the duplication of code just to read from the specified directory and delete files using it, it leaves it open for hacking purposes and the security issue there is much harder to implement as the main program actually determines the changes as well as offers a user account GUI for selecting other folders for consideration (reason for no admin).

[Igor Vartanov]

The issue I'm having is, how to "properly" gain access to the System Temp folder (above) without resorting to altering the access rights on it. The program runs in the user account (because it looks at the %temp% folder and other user based folders added as "junk" folders).

As it looks to me, this is exact reason why services' temp folder should be cleaned by one of the services running service account.

In fact, the most accurate solution would be bringing up native Windows disc cleanup prompt rather than doing what you do, but this is strictly an opinion of my own. And no, I have no idea of how or whether it is possible.

[GuruSR]

As it looks to me, this is exact reason why services' temp folder should be cleaned by one of the services running service account.

In fact, the most accurate solution would be bringing up native Windows disc cleanup prompt rather than doing what you do, but this is strictly an opinion of my own. And no, I have no idea of how or whether it is possible.

I am just trying to avoid writing a completely new piece of software just as a service, the rewrite would entail more work to avoid permission issues (as the users are able to scan/include other folders for cleanup manually, which puts a whole wrench into the works for security). And yes, Disc Cleanup is a good thing, but the Temp folder it touches is your personal account, not the service one and it's rare for a user to even know what Disc Cleanup is or does (or even exists).

[GuruSR]

Well, what I ended up doing was indeed using SeRestorePrivilege, since while looking at the code, I must of been thinking *right* that day, and had written the scanning code modular enough, that I could add in functionality to test the path of the item being worked on, so I devised a way to "mark" the active permission for SeRestorePrivilege and ensure it was only active when inside the SYSTEM account's Temp folder (HKLM\System\CurrentControlSet\Control\Session Manager\Environment\Temp). So since it is modular, it would first scan each folder looking for data to remove, then it would remove that data once it had compiled a database of the files/folders being removed, then it would remove the files, then the folders, all the while testing against the SYSTEM account's Temp path against each item and adjusting the SeRestorePrivilege accordingly. The automatic scanning won't start on timer while the user scanner is open and the user scanner won't open (via user pressed button) while the automatic scan is in progress. So thank you for the SeRestorePrivilege idea and I've safely been testing it for a while and it hasn't been able to remove files I deliberately placed into folders using alternate credentials (IE: .tmp file and folders who are owned by SYSTEM placed in user temp folders).