I have been noticing this for few day in different machine, That in the latest windows builds the permission to access the windows\temp folder is getting changed.
Is this an expected one in windows 10 or in windows 11. Is there any recent changes implemented by microsoft with respect to the temp folder access.
Due to this few application that uses the temp are not working as expected.
Note: I know how to take ownership and gain access to my accounts.
I need to know the behaviors changes that has been implemented.
what exactly is going on with temp access? Can't get any details about the temp access
Related
We maintain an Electron application that stores files in the users' profiles (C:\Users\Username\AppData\Roaming\OUR_APP) and later needs to access them again.
Users who use domain accounts to login into Windows and whose profiles are synced across machines encounter permission issues when our application tries to access the files in this directory. We use Sentry and see lots of error reports like this:
I suspect that this is caused by Windows locking files when it syncs the contents of the AppData\Roaming directory. The strange thing is that the errors we're seeing don't happen when we write these files but when we want to read them (lstat in the screenshot below).
Has anyone encountered this issues with profile data in Windows before and can confirm that this might be cause by the sync process? Are applications expected work around these errors? Are there documented limitations of data you can put into the AppData\Roaming directory?
You are probably using %appdata%. Instead, try:
%USERPROFILE%\AppData\Roaming
I noticed today that on windows 10
some apps in the folder C:\ProgramFiles\WindowsApps... are protected in some way other than just the access permissions.
When installing Microsoft.MicrosoftEmulator_1.1.39.0_x64__8wekyb3d8bbwe.msix or Microsoft.253890156C685_1.0.0.0_x64__8wekyb3d8bbwe.Msix
as well as it seams other apps from the store
the Folders for those created in under C:\ProgramFiles\WindowsApps\ have some additional write protection.
While a cmd prompt started as TrustedInstaller can create and delete folders in the apps that come pre-installed in the folders fo these apps this fails with an access denied error.
Taking Ownership of those folders and files as well as adding full access permission does not solve the issue.
With a cmd prompt started as system it is at least possible to create or delete folders but for the existing folders created by the package installer its still not able to create a file within those.
This protection remains in place even when the system partition in question is mounted by an other windows 10 system.
The only way I found to gain full access to these files is to mount the partition in a windows 7 installation.
So it seams to me that MSFT has added som additional layer or patronizing the administrators which needs to be understood and broken.
Any ideas how to get around this issue?
Well however the restrictions are implemented with this driver: https://github.com/DavidXanatos/IgnoreACLs you can gain access to everything everywhere.
With minor limitations, renaming of files in protected locations does not work and creating of directories.
Other than that, modifying, creating and deleting files and folders works fine.
Power back to the owners of the devices.
So basically I customized a Windows 10 install. I have the PerfLogs, Program Data, Temp and Users folders in C:\ replaced as symlinks to their actual location to D:\
The purpose being, I will only keep a image backup of C:\ and when the need arises that I need a fresh install of the OS, I will only overwrite the whole C: drive with the backup and don't even have to touch my old user profiles. It works without a glitch even as I moved my C: to an SSD.
I did it with a few simple tricks (I don't exactly remember everything I did, but once I got the build right, I just left it as it is as I thought I would never have to touch it again):
I remembered following tips and other guides like this:
https://commaster.net/content/windows-installation-tips-moving-user-folder-another-drive
the difference being I used symlinks instead of junctions with mklink command.
Some modification with registry and other files.
Several stages of booting until everything has been transferred and having windows re-create the profiles and configurations.
Anyways, I had to fix my Mom's PC, which was in a state of disarray as she thought she had to save all her files in C:\ and NEVER in Documents. I opted to install my customized Windows install, so if I need to fix it again, it would just be a cinch.
Before building this custom Windows install, I've made backups of my system with my usual backup tool, Paragon Partition Manager. They worked fine and when I had to change PC builds, such as changing my motherboard, all I had to do was change the drivers. So I thought with my custom Windows 10 install, that's all I had to do for my Mom's PC.
But I kept running into problems with Window's User Profile Service.
At first, it was having difficulty loading the Administrator account and seems to be defaulting to C:\Windows\System32\config\systemprofile, as it cannot seem to write to it's D:\Users\Administrator folder. I quickly fixed that, but, still, it can't load the Start Menu and other services.
The only one that was working almost completely was the user (just one - me) that was existing when I created the backup AND only works with a copy of the corresponding folder in D:\Users\MyUsername.
Obviously I wanted to create a user just for my Mom and one that is completely working and I don't wanna leave a copy of D:\Users\MyUsername in her PC. I figured all I had to do was create a user profile in Control Panel and Windows will recreate everything and all the configurations. The add user service in Control Panel wasn't working with Administrator, but only with MyUsername. But whenever I try to sign in to the newly created user, the "User Profile Service failed to sign-in" keeps popping up. I can sign into it in safe mode, at the first seemingly recreating everything with the first-time-sign-in-welcome-screen, but a lot of the services are not working. So creating another user profile with this new profile doesn't work.
More notably, I've tried:
net user username /add
and adding through advanced user profiles:
control userpasswords2
But the new registry keys for the new users in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList never gets created -- even after I go safe mode and manage to sign in to the new users.
I've also considered it might be a user permission issue, somehow being carried over from my PC build (if that makes sense, it still doesn't to me). Anyways, so with the newly created user logged in with safe mode, I tried changing permission for C: and D: for every single group to "Full Control". Then from that newly created user, create another user either through net user username /add or control userpasswords2. I even tried booting to Linux LiveCD and chmod-ding everything to 777 (I'm not even sure how that transfer to an NTFS. Then I try to sign in and even if I can forcibly sign in, it just isn't a glitch-free user profile.
I'm a programmer not an admin. I significantly modified an old program written in 1997 to run under Windows XP ~7 years ago. At that time, I rewrote in VC++ 2005. The local production network has been updated to Win7. Program updated to VC++ 2010.
Problem: Program runs in new environment but only if user has admin privileges. Without, needed files cannot be accessed. Attempted Fix has been to give user group access to the needed files. Users can access the files "by hand" but program still fails.
Is there a way to give the application admin privileges so that it can access the files?
Not acceptable is allowing users to run as admin. We have to operate under DoD constraints. Is there something I as the guy working on the application can do? If not, what is the solution?
Recap: problem was a large number of scratch files which, in the original application, were being written to the C:\ root directory. The solution was to use "getenv_s" to obtain the user's directory via an environment variable. The pathname was modified such that the string returned from "getenv_s" was concatenated with the scratch file name. Laborious but problem solved.
The huge difference between XP and Windows 7 is the access system (user access control entered with Vista and was further refined in 7). In theory you could run the application as an admin user, or provide a service that would access the necessary system components and files as an admin user. But there isn't a way of giving an application itself extra permissions.
Your other option is to find out what specifically is causing the problem and correct that in your application. Chances are this is a system file or the like.
I am using C# with .net 2.0
I am saving my program data in a file under: C:\ProgramData\MyProgramName\fileName.xml
After installing and running my application one time I uninstalled it (during uninstallation I'm removing all the files from "program data") and then I reinstall the application, and ran it.
The strange thing is that my application started as if the files in program data existed - means, I had old data in my app even though the data file was deleted.
When running:
File.Exists("C:\ProgramData\MyProgramName\fileName.xml")
I got "true" even though I knew for sure that the file does not exist.
The thing became stranger when I ran the application as admin and then the file didn't exist.
After a research, I found out that when running my application with no admin privileges instead of getting:
C:\ProgramData\MyProgramName\fileName.xml
I get
C:\Users\userName\AppData\Local\VirtualStore\ProgramData\MyProgramName\fileName.xml
and indeed there was a file that existed from the previous installation (that I obviously didn't delete, because I didn't know it existed).
So just guide me how could I stop this when apps running with no admin right.
I do not want to create any file automatically in VirtualStore folder. Please discuss all the possible ways to stop this.
First, ask yourself, do this need to be globally saved for all users?
If it doesn't have to be, save the file in Application Data instead, you can get the path with Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), it should always reliably expand to C:\Users\Username\AppData\Roaming\. Do note that this path is unique for each user though.
If you have to, you're out of luck. There is no reliable way to store application data for all users without admin rights (or UAC) on any Windows post-XP that's not extremely hacky, like storing your data in the Public user (which may or may not be possible, I can't check right now).
An approach to solving this is to use the Environment.SpecialFolder.CommonApplicationData location, but with some very important caveats & setup.
CommonApplicationData is
The directory that serves as a common repository for
application-specific data that is used by all users.
This location is described further here and here.
Important requirements and restrictions are given in another SO answer: https://stackoverflow.com/a/22107884/3195477
which said in part:
The recommended solution is for your installer to create a sub
directory of C:\ProgramData for your shared storage. And that sub
directory must be given a permissive ACL by the installation program.
That is what grants the desired access to all standard users.
Otherwise the program running with standard user permission will still not be all equally able to read/write files in that location for all users.
I found a work around for this issue when transferring a very old win32 app to windows 7 & 10. The program wrote to a database on C:\Program Files... but the OS auto changed the path to virtual store. However the database was required globally. By changing compatablilty mode to Windows 95 or XP SP2 and always running as administrator the database was worked on directly in C:\Program Files\etc.
There are security implications for this and the box was removed from all networks and adapters disabled etc.