I am calling CreateFile() to create a file in the Program Data directory. I'm using SHGetSpecialFolderPath() to get the dir name.
I have a user with Vista for whom CreateFile() is returning error 5 (Access Denied). It would help if I knew where CreateFile() was actually attempting to create the file so we can check his folder permissions. The problem with Vista (UAC) is, it's not attempting to create the file in the directory I passed in. It could also be in a VirtualStore directory. An added source of confusion is this user is German and although SHGetSpecialFolderPath() is returning "C:\Program Data\blah blah" as the path, I don't think that's actually where the path is. I think German Vista uses the German word for "Program Data". I would like to be able to tell the user "This is the exact path where we are trying to create the file. Check your permissions on this folder."
I know you can get the a path from an open file handle, but in this case the CreateFile() is failing so I don't have an open handle. How can I get Vista to tell me the actual path where it's attempting to create the file?
Fire up Process Monitor and watch what it does:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
If with UAC the paths used are not the ones you want, then the redirection is in effect.
To make sure that redirection does not occur, add a manifest to your application which indicates to Vista that your application is properly coded and aware of access restrictions (i.e., you don't write to e.g., HKLM or the programs folder if your app doesn't need admin privileges to run).
But your application should be able to write to the APPDATA folder (if that's what you really use).
Make sure you're using CSIDL_APPDATA and not CSIDL_COMMON_APPDATA (the latter one being accessible only with admin privileges).
To find the real path (the one you would expect) tell the user to type %APPDATA% into the explorer bar (or hit Windows+R, then type %APPDATA%, enter). This will open the explorer on that folder.
My understanding is that ProgramData is used by Vista to write files that were attempting to be written inside C:\Program Files, but failed, since unless you are running the app as Admin you can't write inside program files. Maybe you should try saving your files to the AppData folder under the current user.
Related
I have an EXE file, and i whant to launch it every windows start for all users.
am adding a registry key on :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
My EXE works fine, but it can't access to any other file (.txt) even the required file is in the same location.
it seems like an access denied. why?
My Exe is a .NET application (C# console application) reading a text file content.
Solution from #HansPassant :
Always use full path names for files, c:\foo\bar\baz.txt. Just baz.txt will not work, the Environment.CurrentDirectory is not set where you hope it is. Use AppData, if necessary use Path.GetDirectoryName(Assembly.GetEntryAssembly().Location) to know where your EXE was installed.
Someone recently raised a bug against a filter driver I've been working on. They said that I'd made it possible for a limited user to delete Windows files even if they remove the permissions on the file for the user to be able to do that.
I've been looking at it and it's nothing to do with my driver, even a fresh install of Windows allows this. If you:
Logon as a user called "limiteduser" who's a non admin.
Create a text file
Edit the security for the file
Remove inherited permissions and remove "limiteduser" from having any rights to the file.
Once you've done this you find that:
You can't changed the contents of the file.
You can't rename/move the file or send it to the recycle bin
However you can:
Delete the file in explorer with shift-delete
Delete the file with cmd.exe (del myfile.txt)
Why is this? Is deleting files always a property of the parent folder? And if so why isn't renaming files?
I know this answer isn't complete at all, but I hope it will be helpful nonetheless.
You didn't mention which version of Windows you are using, but as the ones that use any version of the NTFS file system should behave the same I believe it doesn't matter.
The documentation on "File and Folder Permissions" in Windows 2008 Server states that:
Groups or users that are granted Full Control on a folder can delete any files in that folder, regardless of the permissions protecting the file.
So it would appear that part of the answer to your question:
Why is this? Is deleting files always a property of the parent folder? And if so why isn't renaming files?
would be that deleting is indeed a property of the parent folder - it looks to me that it's the Delete Subfolders and Filesspecial permission that allows you to override the permissions on the file.
Why the "Full Control" permission on the folder won't give rename permission is unclear to me, but my guess is that it's actually only Delete Subfolders and Filesthat has the power to override; to rename a file you would have to have permissions to write too.
I'm guessing that the reason that "Shift-Del" in Explorer and "del" in cmd works and not "Recycle" would be that recycling is a move/change operation.
See this Technet article for reference: How Permissions Work
In matlab, I used a windows standalone application. There is a line in this application that writes a file in C:\...\...\. When I run the output exe file produced from this windows standalone application, the exe doesn't write in C:\...\...\ neither tells me that there is a security issues in that partition. All the execution does is nothing. But, when I right-click and run the exe as administrator, it runs correctly.
I want to do it without right-click and run as administrator. Are there is a command in matlab that can do that?
If you create a shortcut to your application, you can go to the Properties of the shortcut, click on Advanced in the Shortcut tab, and select "Run as administrator". That way, whenever you start the application from the shortcut it will be run as an administrator.
(Disclaimer: applications really shouldn't "foul their own nest" by writing into Program Files. This is bad design.)
Starting from Vista, unprivileged processes are not allowed to write to protected folders such as Program Files, because Program Files is designed to store code and not data. However, since this limitation has not been enforced in XP, MS has provided a backward-compatibility hack in the form of Virtual Store. Now, when a program tries to write to protected folder, its output is being redirected into a dedicated folder. This way, the program still "thinks" it writes to its usual location, while in fact it writes to an unprotected location. However, when you later check the Program Files location, you might not see the file - because it's not really there.
You can find more details here: User Account Control Data Redirection.
If you are administrator, add full control permission for your username to the destination folder. You do that by right clicking on the folder, going to properties and then security tab. Then edit and add you username with Full Control rights. Then you don;t have to run the the program as an administrator.
There is no way you can elevate a process once it is started, so Matlab cannot possibly have a command for that. Just running Matlab elevated.
I have an addin program that works with MS Word (version 2007). It is located in the C:\Program Files location. I installed Windows 7 and then went to make a routine change to my files in this location and it would only bring up a read only file. How can I grant myself permission to write to my own program? I cannot change this location or use any other workaround. I have this product out to 25 different companies and I can't change the programming to work from any other location. Thanks
You could also embed a manifest in your EXE that makes your program require adminrights on Windows 7 / Vista.
On Windows Vista, UAC means that users run without admin rights and don't have write access to the program files directories.
The correct solution is to write to a folder for which standard users do have write permissions.
The solution you are looking for is to make your app's folder within program files writeable to all users. You can do this by adding a DACL when installing. It is extremely bad practice to allow standard users to write inside the program files directory and I urge you instead to re-code your app so that it does not need to write there.
Assuming you're doing this as part of modifying the config (and not when your application is running for regular users)...
Your user account probably doesn't have the correct permissions to write/modify the file. Assuming your account is an administrator account, right-click the file, select "Properties". Click the "Security" tab. Click edit and give your user account Full Control.
If you can't do this, it's probably because the ownership of the file doesn't allow you. If this is the case, click on "Advanced", go to the "Owner" tab, and click "Edit".
However, if it needs these permissions when it's running, you should instead be using the %AppData% folder.
I installed my application in Windows 7 and as part of the installation, it installs some text files. Now, if I open the text file in notepad and try to save it, I get an "Access denied" error. I'm logged in as administrator on the machine and the file is not marked read only and security permissions seem to be fine.
However, I could delete or rename the file without any problem and I could create a new file with the same name/location using notepad and the save works fine.
I understand it has something to do with UAC. I'm wondering what UAC does in order to block access to the file. Our application is not installed in Program files folder as I believe UAC restrict any changes to files in Program Files folder
Can anyone throw light on what is going on.
regards
G
With UAC, just because you're logged in as a user with administrator privileges does not mean a program actually runs with them. The program has to either request privilege elevation (which gives the "Do you want to allow this program to _____" UAC pop-up) or explicitly be run as administrator (right-click on the program/shortcut and choose Run as Administrator).
By default most areas of the drive outside of the standard "user files" (a.k.a. My Documents & co.) are restricted to administrator-only access, but the folder permissions can be changed to add access for a particular user if desired.
You will find that saving files almost anywhere except the "my documents" area for the user will be restricted, this includes saving to other drives on the system etc.
If you check the permissions for the directory you are trying to write to, all you have to do is expressely give the user permission. Otherwise only the admins have permission, which requires UAC approval from the user to get the admin token.
You normally get "Access Denied" error when the file is in use. UAC could not be an issue here. Check out if the file is in use by anyother process.
You can use tools like Process Explorer from sysinternals to do that.
You have to right click the file and select properties. THen open the security tab and you can see different accounts with differet privelages. Click USERS and it should highlight. The box under it should have a bunch of check marks that indicate what this user can do. Click Full Control. Apply and Okay. Then you can save!!!