|
I have a requirement to prevent the user from adding, renaming, or deleting folders and files. I've never done Windows hooks before.
Is this possible? Can someone point me n the right direction?
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
There are no hooks per se for NTFS. You'd be writing a filter driver for NTFS.
Why couldn't you do this with standard NTFS permissions?
|
|
|
|
|
I didn't mention NTFS. I don't really have any preference as to how it's done.
How do I do this with file permissions? Maybe this[^]?
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
What are you doing and why are you hell bent on doing this in code?
|
|
|
|
|
It's a requirement for an app I'm working on
If it's not broken, fix it until it is
|
|
|
|
|
That doesn't answer my questions at all. What's the point of doing this at all?
|
|
|
|
|
To prevent the user from doing anything to app controlled folders and files.
If it's not broken, fix it until it is
|
|
|
|
|
If you're talking about under the Program Files folder you don't have to do anything. Everything under Program Files is ReadOnly to normal users.
But, what already exists depends on where you're these files/folder you're talking about are in the directory tree.
|
|
|
|
|
I have an app that has folders created and files copied to it without the user's interaction. Then permissions are applied.
If the user does not have rights, then they cannot add files, rename them, delete them, or likewise manipulate folders.
If it's not broken, fix it until it is
|
|
|
|
|
Your application will be running as the user that launched it. Your code cannot give more permissions than it already has from the user running it. Also, any changes to NTFS permissions are done as the user running your code. There is NOTHING preventing the user from just putting the permissions back that your code took away.
Permissions are just about never set in application code at run time but set at install time.
|
|
|
|
|
True, but what if I run my code using impersonation? Then the user who created it (my app) would be the only one that could manipulate it, right?
If it's not broken, fix it until it is
|
|
|
|
|
Normal users cannot impersonate other users.
|
|
|
|
|
There has to be a way to prevent a file from being touched by the user. I've see apps that somehow lock the file so no one but that app can manipulate it
If it's not broken, fix it until it is
|
|
|
|
|
And those apps are easily defeated. I've never seen one that couldn't be worked around with just a working knowledge of permissions and, in other cases, how ZIP files work.
So you're saying a user creates a file in your app and saves it and then loses all permissions to manipulate that file later on? That's a very unusual situation.
|
|
|
|
|
No, there's a service running. It detects a file on the server which is then copied to the user's PC.
The user should not be able to do anything to the file, or the folder it's in.
If it's not broken, fix it until it is
|
|
|
|
|
Your application can talk to a service that's running as an account that has sufficient permissions to set/remove permissions on folders.
This is a management nightmare, requiring a good working knowledge of how permissions work and are inherited in the NTFS tree. Such an explanation is beyond the capacity of forums posts.
Now, there's another way. Screw all the management of granting and taking permissions. The service would be the "file manager" in a folder where only the service account has permissions to write files/create folders. Your application could ask the service to save files/create folders as appropriate and the service would do all the file/folder work on behalf of the application using the permissions granted to it by it's own user account. This user account has to be specially setup to login as a service and has the appropriate permissions to where the files/folder will be stored.
|
|
|
|
|
Do you mean a Windows Service running under it's own account?
If it's not broken, fix it until it is
|
|
|
|
|
|
It probably would work OK assuming my installer created the account for the service.
If it's not broken, fix it until it is
|
|
|
|
|
Kevin Marois wrote: There has to be a way to prevent a file from being touched by the user.
Not in Windows.
The user is the owner of the PC. Whatever code you can come up with, I can attach a debugger, halt and jump.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I understand that a developer can circumvent my app - I'm talking about your average user with no programming experience. This app isn't targeted to programmers.
If it's not broken, fix it until it is
|
|
|
|
|
A user doesn't need any programming experience to circumvent your security. They just need a passing knowledge of permissions.
|
|
|
|
|
Kevin Marois wrote: This app isn't targeted to programmers.
You are effectively asking how to keep something private on a machine that ain't yours. You could 'hijack' the data, encrypt everything and keep your encryptionkey on a server. Not a good way to formulate it, but the question here is ownership. If you don't want them to access a file, then don't have it on the local machine.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Open the file in your app, and do not close it while the application is running. Make sure you set FileShare.None when opening the file. Of course, when you close your app, Windows will close the file, and now the user can access it.
|
|
|
|
|
This is related to core operating system fundamentals. If you control the environment (ie are an administrator on the machine where it's installed) you can lock it down. Otherwise, not gonna happen and any attempt on a distributed application would reek of malware.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
