I have an app that keeps most of its files in a directory, and I need everything in that directory to be readable and writable by any user, regardless of who was running the program that created them.
I'm installing the app using Indigo Rose's SetupFactory, and I am using their permissions facility in On Post Install:
File.SetPermissions(SessionVar.Expand("%AppFolder%"),
SID_EVERYBODY, SET_ACCESS, ALL_PERMISSIONS, SUB_CONTAINERS_AND_OBJECTS_INHERIT);
And for the most part, this works. The directory is accessible, and everything it is accessible, except for the one thing.
I have a utility program that constructs a configuration file. When it is run as administrator, the file it creates is not accessible to other users. It's properties allow access only to "SYSTEM", "Admin", and "Administrators". Files I create with Notepad, from Windows Explorer, by redirection on the command-line, etc., when running as the administrator, allow access to "Everyone", and to "Authenticated Users", as they should, given that those are the access rights provided by the directory, and the directory has Apply to: "This folder, subfolders, and files".
The question is why is this one file, created by this one app, not inheriting permissions from the directory, as it should?
There's nothing odd about the app. It's a simple C# app that constructs a string in memory, and then writes it to the file with:
FileStream fs = new FileStream(fileName, FileMode.Create, FileAccess.Write);
I don't see how it could be simpler. But what could be going wrong?
Related
I'm trying to use cx-freeze to create an installer for a program that I'll distribute to my colleagues. I'd like to set the default installation location as the user's username folder (e.g., C:\Users\myUserName) in my setup.py file.
options = {
'bdist_msi': {
'initial_target_dir': <Username Directory>
}
}
However, the Windows system folder properties reference doesn't seem to mention a keyword that would let me access the username folder directly.
I tried building the path myself using the USERNAME property, i.e., passing in the argument C:\Users\[USERNAME]. However, the installer simply drops the USERNAME argument and returns C:\Users.
I took a look at this question on setting a folder as a system folder, but that would set the path string to whatever the developer's username is when creating the .msi file rather than the end-user's username. (Using os.path.expanduser() would do the same thing; documentation here.)
Does anyone know of a keyword that would allow my installer to dynamically access the user's username directory?
We are creating an application that updates it's files under Program Files - we've run into some permission errors and were starting to wonder who should be owner of files - the "SYSTEM" user or the one that installed the software? After inspecting the "Program Files" folder we see that some software binaries have the user as owner, some "SYSTEM". We are failing to overwrite some files and the only weird thing seems to be that the owner of our updater binary is the "SYSTEM" user.
Is always better to install apps that needs write permissions in a folder under C: or you can look at ntfs permissions on that folder and add your users.
when i save java file error is you dont have permission to save in this location contact the administrator to obtain permission on window7
Don't store application data in the "Program Files" directory.
It is very bad design and regular users don't have write access to that directory (for a very good reason).
So even if you changed your settings locally to open up the door for viruses your application won't run on other computers.
Besides: storing a Java file in the JDK directory serves no purpose at all.
Btw: your uppercase letters are broken, as well as the dot or the comma...
That's normal - jdk/bin is the installation directory of the JDK, regular users cannot (and should not) write files there. You'll have the same problem on Linux/Unix and on Mac OS X, where installation directories are off-limits to regular users.
Write your files to the users home directory (System property "user.home", works across platforms), or let the user choose where you save stuff.
Bin directory do not allow directly to save program in it.
it is so simple, just save your .java file on desktop and then copy paste it in Bin. done ;)
If the file can't save directly to c:\program files\java\jdk1.8.0\bin\
Solution:-
Click start Menu type Notepad command in run run as administrator
Right click the Notepad run as Administrator, then type the program file can save directly to c:\program files\java\jdk1.8.0\bin\
Just try it......
We have a web app running on a Windows server, which allows a user to do some processing and download the results. The result is a set of files which are dynamically created on the server and zipped into a single file for facilitating the download process.
Everything works fine on Windows, but when users download the file from the web app on a Mac, the contents of the zip file have the execute (chmod +x) permission set (I presume that the same happens on *NIX and Linux machines). This can, of course, be removed by running the 'chmod -x' command, but is there a way by which one can remove the execute permission on the files, so that when downloaded on a Mac, the files don't have the execute permission set by default?
I believe it's not possible - .zip files don't contain permissions, so on a Mac it has to default to "most permissive" (otherwise it's possible that there are applications inside the zip that wouldn't be marked as executable when they need to be).
tars, for instance, do record permissions, but that'd be a bit more difficult to create on a Windows server.
I've a windows service that updates our product. It copies the product files into a temp directory, usually "C:\Windows\Temp", patches the binaries, and then uses MoveFileEx to copy the files back to the install directory on a reboot, usually "C:\Program Files\Product". The files in the install directory are inheriting their security attributes from the parent folder. After the copy, patch, and reboot, the files in the install directory are missing some ACLs. Specifically the files don't have the ACL for the Users group anymore so users can no longer run the program after the reboot.
Can anyone explain whats going on here? It seems that copying from the install directory to the temp directory, the files inherit the ACLs of the temp directory. On the MoveFileEx/Reboot, though, the files only inherit the ACLs that both the install and temp directories have in common.
In Windows if you copy a file the file takes on the ACLs of the destination directory. If you move a file the ACL goes with it overriding any it might inherit from that directory. I'm not sure how MoveFileEx might operate differently on a file.
The temp directory is usually located under the user profile (both %TMP% and %TEMP% usually point here) so copying files here will have permissions for that user. Moving those files to the program files directory will take only that users rights with them and therefore only runnable by the installing user.
One potential workaround is to patch copies of the files with-in the same directory but with different names. After the reboot, the patched versions could be swapped in. Alternatively, do a reboot first and then patch them in-place, and just back them up to the temp directory in the event a manual rollback is required.
If you really want to move them to a different location, creating a temp folder in the same place as the files to be patched would help the permissions stay the same assuming the directory is using inherited permissions.