I'm trying to use CreateAppContainerProfile to run a .NET 6 application.
Based on the documentation that api is used to set up the same kind of sandbox used by UWP applications.
Now this works correctly if the application is installed below c:\program files but if it's installed elsewhere the process fails with "Failed to resolve full path of the current executable [path to the executable]" (code 0x80008085)
If the user account has the WRITE_DAC access right to the application folder I can allow the sandbox read/list_directory access and it works again, but if the user account itself only haves read/list/execute rights there I can't do that.
The documentation for UWP sandboxes say that they implicitly give the sandbox read access to the application directory (which makes sense) and considering the application works in c:\program files without granting any permissions, that seems to somewhat also apply here but I don't understand why it doesn't work the same elsewhere.
Is there some security settings on the folders outside the user rights that would be relevant here?
There is so little documentation on this functionality I'm not entirely sure where else to look for information.
Answering my own question here:
I did really overthink this by assuming that the app container was supposed to magically give read/execute permission to the application directory.
In reality, c:\program files simply has an ACL for the special user "ALL RESTRICTED APPLICATION PACKAGES" that grants all app containers read/execute access to the entire directory tree.
Unfortunately this means there isn't really a nice solution for what I'm looking for apparently. At some point my main process has to be elevated to change ACLs to the application directory so that the app container can read it, there is no way afaict to just "inherit" rights the host process has to the containerized one.
"Capabilities" can be used when creating the appcontainer to allow access to certain predefined functionality (libraries, devices, ...) or you can basically set up custom capabilities, like a set of directories a container should be able to access but that then again requires the right to change ACLs on those directories when setting up the capability.
Related
I have a visual studio setup project which installs my files to the program files folder and also writes some stuff into the registry and in addition some of the files are com visible (so there is more confusing stuff written to the registry).
Therefore I have to install it as an administrator - this works fine. And this administrator and every other administrator is able to start the program. But using a standard user I am not able to start the program.
All registry entries are there for the standard user - and it also has enough rights to access the file in the Program Files folder.
Could there be a problem with the ComVisibility? (Which is needed because it's actually a DLL working as a plugin for Solidworks)
You just need to look at the code in your app and see what it does that limited users can't do. Installing it for all users does not mean that it automatically allows limited users to violate security. Just find out what it's doing when it gets the security error (which is what you believe it is).
Limited users have never been able to write to restricted areas such as the ProgramFiles folder, CommonFiles folder, HKLM etc. That's a common reason for limited user issues with apps.
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'm writing a desktop app and need a folder which...
Exists in Windows 7 and Vista
Is common to all users (for store config data).
Application can save data on it, without Admin privileges (not like "ProgramData").
is standard (I don't want to create another app specific folder in "C:", the Desktop or other place alike.)
"Program Files" is not an option, of course.
Can you suggest an appropriate folder, or better use the Registry?
The recommended way to do this is to create a folder at install time, dedicated to your application, underneath "ProgramData" (i.e. CSIDL_COMMON_APPDATA/FOLDERID_ProgramData).
As you already know, the CSIDL_COMMON_APPDATA folder is read only for standard users. So your install program needs to give the folder that it creates an ACL that permits the access that you require.
This is the solution that meets all the criteria laid out in your bullet points.
You mention the registry. There is no area of the registry that is shared between all users and yet writeable by standard users. Whilst you can use ACLs to grant more permissive access rights to the registry, it is really not the done thing. Please forget that I even mentioned this possibility!
IF your app is .NET then use CommonApplicationData - you can get the real location by calling GetFolderPath.
EDIT - as per comments:
You need to setup ACL correctly - for sample source code on how to do this see http://www.codeproject.com/Tips/61987/Allow-write-modify-access-to-CommonApplicationData
What about Public User directories? For Example: C:\Users\Public\Libraries or C:\Users\Public\Documents
I've noticed these folder on several of my Windows 7 machines. I'm not sure if it is always there, but might be an option. I was hoping for something like an %appdata% for the Public User, but the closest thing I found was Public\Libraries.
(As a side note, it appears C:\Users\Public\Desktop does require admin to write to.)
what about using %APPDATA%/Company/Product for the directory?
I found out an application I wrote does not work properly under Windows Vista/7 if UAC is enabled at any level, because it writes files to the install directory of the program, defaults to "C:\Program Files\MyProgram." If UAC is disabled (or on any other version of Windows) it works properly - I read that UAC denies applications write access to the Program Files directory by default.
My question is, well, how should I write my application so that it can be used without any "rights" needed at all. I don't want users to have to run it with elevated privileges or as administrator. I just want it to work. Are there certain directories that any app has write access to under UAC where it might be better to write my files? They are mostly config files that are dynamically created/destroyed/updated.
Thanks for you help!
Per-user application specific data should be written in the AppData folder.
You should use SHGetKnownFolderPath with FOLDERID_LocalAppData.
In managed code, you should use System.Environment.GetFolderPath with System.Environment.SpecialFolder.LocalApplicationData.
Yes, there are specific locations. Consider this msdn article as a first reference. It mentions the locations:
CSIDL_APPDATA
CSIDL_LOCAL_APPDATA
CSIDL_COMMON_APPDATA
In native code, the method SHGetKnownFolderPath should prove useful.
In managed code you can use Environment.GetFolderPath(). If you're in a specific application framework, such as windows forms, you can get even easier access via direct properties, such as Application.LocalUserAppDataPath (which is my personal favorite technique). The framework path will include app-specific qualifiers on the path it returns to distinguish between (e.g.) different versions of your app.
I'm building a product that involves
a windows service caching data on the local machine,
user processes reading that data and writing their own data,
the service in turn writing back that data to a server.
Where should I put the data files for this, such that they'll be shared by all users and read/writable? The software will operate in a corporate environment where desktops are sometimes pretty locked-down, so for instance some users won't have write rights to C:\Program Files.
I don't think C:\Documents And Settings\All Users\Application Data\ is a good candidate - I think by default only Admins & Power Users have write access here.
I could use each user's Application Data folder, but this would be a bit of a pain as different people could use each machine ... so it'd be simpler if there was just one shared location.
I'm developing in C# .net 2005, but that's probably not too relevant.
Unfortunately you have no real choice. You must (you really must) call SHGetSpecialFolderLocation to get the path to c:\users\public\AppData (which is the name of the folder you linked above, but on Vista and possibly Windows 7)
Then you MUST create your own app folder therein. And then, you MUST, use the security APIs to modify the ACL of the created folder.
There is NO folder on the system with a default ACL that allows multiple non administrator users to read AND write the same files.
c:\users\public\AppData is the closest. Modifying the ACL of a application folder here seems the best approach. Of course, once one has resorted to ACL modification, the folder really could be created anywhere at all. But that could surprise system administrators and result in weired security holes.