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.
Related
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
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.
The problem is put as follows:
I installed my VS2013 on a FAT32 disk and it works nice except with windows 8 app development, where the XAML designer just won't open while requesting elevated privilege of running "icacls" commands, of which I approves of course, to modify the permission on the IDE folder to gain access to it, only to fail because it's FAT32 and it just doesn't have any permission mechanism. As a result, the designer says that it doesn't have the permission to specific folders, which makes no sense to me.
Previously I installed VS2012 on C: partition, which was NTFS and ran into the same issue. However, I solved it by assigning proper permission on destination folders. Yet this time, it doesn't work in that it has no option for permission and security on a FAT32 partition except "hidden" and "readonly". I have also tried other tricky ways like trying to link the IDE folder to a duplicate on a NTFS partition, but haven't found the solution yet.
Is there anyone out there who knows any workaround or runs into the same issue?
FYI, the exception thrown by VS designer:
System.Security.SecurityException
Designer could not be started because of a permissions issue on the drive to which it is installed. Please check the permissions of the folder before trying to start the designer.
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.
I have a setup project that installs my app to the typical program files directly.
My app periodically saves some temporary images to the apps installation folder. It seems on Vista, the permissions are not setup for write permissions. I can change it manually in windows explorer and it works, but I would rather have the setup project do that automatically.
How can I do this?
Is there a better/more normal place to put temp images that won't have permissions issues?
It is not Vista specific, this will happen with any kind of user account that doesn't have admin privileges. Your program just can't write to folders like c:\program files\blah. That UAC disables admin privileges has been publicized for a long time now. Use Environment.GetFolderPath() to get the path to an ApplicationData folder that you can write to.
See http://msdn.microsoft.com/en-us/library/bb756940.aspx for details on UAC issues for vista. These problems can also occur in other versions of windows when running applications from non-admin accounts. You should only write data to app data or temp directories and not program files.