I develop an application on WPF. I have recognized that some parts of the program do not work without Local Admin rights. On another question it is said that writing to event log was causing the need of LA rights. What other possible causes there are? I want to know these that I can find the cause of this problem easily.
There won't be anything specific to WPF as that's just the graphics side.
What it will be is common things like writing to the event log (as you've mentioned) or writing log files to certain locations on the harddrive or writing to the HKEY_LOCAL_MACHINE area of the registry.
If you make sure that your writing to the user owned area of the disk and registry you should be OK.
It has nothing to do with WPF. It is more based on the operating system and your login creditials. If your login credentials don't have permission to write to a file then your application will not be able to write to a file.
To work around this, you could add an app.manifest file to your .exe project. Once that is added, then you should open it up and change the <requestedExecutionLevel /> node to have a level of highestAvailable. That should help you out.
Related
I'm writing an application for Ubuntu, which allows you to customize the Unity 2D desktop environment.
Some settings, I can change using Dconf, which is user-specific. So if one user changes a setting, it only applies for that user.
For other settings, however, I need to edit text files which are located in /usr/share/unity-2d/, to which a normal user can't write. To solve this problem, I thought it was a good idea to have users run the application as root, which makes sure they have access to /usr/share/unity-2d/. Only, when the application is running as root, and one of the Dconf settings is changed, it gets changed in the root user's Dconf, so the changes don't apply to the actual user.
I need to find a solution to this problem, and my first realistic idea was to use PolicyKit. I need to make sure that my application runs as the current user (so not always as root), but that it does have access to /usr/share/unity-2d/ and the files inside it. I'm writing the application in C#, using the Mono framework. I don't really have any experience with PolicyKit, and to be honest this is my first attempt in making a serious Linux application.
My idea was PolicyKit, but if one of you has another (realistic) way to achieve this, that fine with me as well. If it comes down to using PolicyKit, I'd like to have a bit more information on how to do this, and what everything does, please. I know I can probably just run my application using pkexec, but I was actually thinking more among the lines of a button in my application to unlock the features which need access to that directory, which at that moment asks for a password to get writing access to the files in the folder. In this way, people who don't have special permissions on the system the application is running on, can still customize some basic settings.
Well, the obvious solution is to have two processes, one normal user app with the GUI, and something that runs as root that manipulates files as root.
E.g. as an analog "commandline only" issue would writing a file as root:
sudo echo Hello World >/root/hello.txt
Does not work because the redirection is done by the interactive shell and it does not have root's access.
The classical solution is to use two processes:
echo Hello World | sudo tee /root/hello.txt
Now the /root/hello.txt file is opened by tee which runs as root (via sudo), which is allowed.
I'm not sure if the question's title makes sense, and I'm sorry if it doesn't; I didn't really know what to title it.. Anyway, is there a way to make your program track the viewing of a folder?
What I'm trying to achieve: Windows 7 Home Premium doesn't allow encryption. So, I made a folder inside my user directory, and set it to hidden. Although, you can easily find it by changing windows settings.. So, is there a way to make a program pull up a window if the user tries to access that certain folder?
I don't think you can detect the "opening" of a folder.
Instead, you may want to set a FileSystemWatcher to detect any file access to the files in that particular folder.
Hope this helps.
First of all, I have to wonder why you're not just setting an ACL on the directory to prevent access.
However, it sounds like you want to find when somebody is accessing a particular directory. To do this, you enable filesystem auditing, then set the audit ACL to generate audit entries for "List folder". This will cause entries to be generated in the Security Event Log whenever the directory is viewed.
Now you just have to write a program that watches the Security event log looking for entries indicating that somebody has listed the directory in question and take action as necessary.
Well, there is an article on code project describing how you can hook into windows system calls: http://www.codeproject.com/KB/system/hooksys.aspx - it's not simple though (and also not C#) and has the potential to screw with your system but if it might be a fun project to work on.
A simpler option would be: Use a 3rd party desktop encryption tool - not much programming involved here but it might do the job better than anything else.
When we create a SetUp & Deployment project for our application in .net, the default folder for our application to be installed is being set as C:\Program Files.....
Our application will run perfectly if we are using a Windows XP machine. But if we are using a Windows Vista or Windows 7 machine, the application wont run perfectly, especially if we are performing any file operations in our application...
Can anyone find a solution for this problem? Is there any means to penetrate this User Account Control and File Access Controls of Windows 7? or can any1 give a choice to change the default installation folder from [ProgramFilesFolder]\[Manufacturer]\[ProductName] to some other folder?
If your application writes to any files under its install folder (i.e. under Program Files if default path is used), then it is badly written. You shouldn't try to circumvent OS security mechanisms to protect the user from badly written apps; you should rather fix your app so that it works correctly.
And it is, of course, not a .NET issue at all. Any application doing the same thing, no matter which language/framework it's written in, will have the same problem.
You should still install your application in Program Files folder. there are good reasons to have it there - a single copy for all users, in a well known locked place where nobody but an admin can tamper with your binaries.
However, any file operation you are doing should be in one of the standard Windows locations for user-writable files. There are several such folders, depending on the file usage model. You can read more about these in the following SO questions :
My winform app uses xml files to store data, where should I store them so Vista users can write to them?
Vista and ProgramData
Data shared among all users should go in C:\ProgramData (use Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) to find out where it actually lives -- it can be different between Windows versions).
Data specific to the user should be in SpecialFolder.ApplicationData. If the user has a roaming profile, this is shared between machines.
Data specific to the user that's also specific to the machine should be in SpecialFolder.LocalApplicationData.
If you really need to put something in your program's installation directory, you need to do this with Administrator privileges.
You should either do this by prompting for elevation the first time that the program is run. Preferably, you should do this during installation (because you're already elevated).
First of all, you should not set your app to install under C:\Program Files\..., you should instead set it to %PROGRAMFILES%\... While these will usually equate to the same thing, they can be different on a 64 bit system, or they can be wildly different if the system has been set that way.
As already mentioned, don't try to circumvent the UAC, it is there for a reason, and your program is no more special than any other program on the system. Instead what you should do is set your app manifest to demand administrative level permission upon launch (which if granted bypasses the file system virtualization, although the user can decline it or possibly not even have the rights to launch something as admin). The other thing you can do is set the ACLs on the folder that your app sits in, and give all users on the machine read/write access to that folder (this would have to be done at install time).
Or you can do things the proper way and store your data files in the %APPDATA% folder, which you have full rights to, although these folders are specific to each individual user of the system.
I'd suggest start here http://channel9.msdn.com/pdc2008/PC51/
That will give you a good foundation.
In a WPF application I use .txt files for holding some information. An application can read and write data from/to .txt file. Everything is OK, but the problem is that, to achieve this purpose, I have to grant writing access rights to these files for a user of an application and so, he/she gets the possibility to edit these files manually.
How could I set editing .txt files access rights for an application without granting the same level of rights to a user?
Edited (added):
After getting some comments and answers, I put the question this way (just to make my question more clear and not restricted to user access rights scope): How I could prevent the user from changing the file manually?
Encrypt it, or digital sign it
I'm going to presume that you are not trying to prevent the user from changing the file manually, you just want to prevent the extra step of specifically assigning rights to the file.
You are most likely writing to a file that is in a protected area (an area that became protected after UAC was introduced). To avoid this, write your file to one of the "approved" areas, such as %APPDATA%. Here is a list of a few more (assuming C is your boot drive):
C:\Users\username\Documents
C:\Users\username\AppData\Local
C:\Users\username\AppData\Roaming
C:\Users\Public\Documents
C:\ProgramData
This article has a whole bunch of info around that which you can cherry pick bits from.
This might be an overkill, but you could create a service that runs on a different user account, which can edit the file. Then your application would use that service to access the file.
This way you can prevent unwanted changes and/or log every change to the file.
I have a windows Application that stores certain files in a directory. I would like to know if there is a way in .net that I can restrict users not to have access to that directly (by just going to that directory in windows, and grab files) so only my application can add/verify/delete a file in that directory.
Could you use the Isolated Storage in .Net? While, it isn't necessarily restricted away from your users it may be a lot harder to find.... (stores under the local settings\application data\isolated storage for the logged in user)
Via code you work with it by using / importing the System.Io.IsolatedStorage and then you can create directories, files, etc... normal.
You also don't have to keep track of the actual directory on the HD it's in as .Net manages this. Maybe a nice plus.
This is only possible if your application runs with different credentials than the user running the application.
By default all applications run with the credentials of the user who launched the process. This means the application has the same directory and file restrictions as the user. Without a different account, the application can only decrease it's ability to access the file system, not increase it.
Dealing with the file system is evil in general. Even if you could get the user to not play in that directory you still can't trust the results will be in the exact same state as you left them. It's possible for other users, physical disk corruption or any number of other things to corrupt your files.
The only way to sanely program the file system is to expect failure from the start and count yourself lucky when it actually works.
The application needs to run as a specific user - and that user will always have the same rights as your application. You can, potentially, make a service that runs as an administrator to prevent standard users from accessing a directory, but the administrator will still be able to change things in the directory.
I suggest you look for another approach for your problem. There are potentially alternatives - perhaps you should consider keeping some type of encrypted hash on the directory contents. That would at least allow you to verify that the contents have not been changed, although it won't prevent the change from occurring.
As others have mentioned, you need the application to act as a different user than the ones currently logged in. You should look into 'impersonation', here are some links that can get you started on getting your application to act as a different user when performing certain tasks:
http://csharptuning.blogspot.com/2007/06/impersonation-in-c.html
http://www.codeproject.com/KB/cs/cpimpersonation1.aspx
The easiest (although not secure in any way) method, would be to use a hidden folder, which the users know nothing about. so \servername\hiddenfiles$
A more secure alternative would be to change the credentials the program is using to access the folder. Is it necessary for them to access it as themselves?
An alternative would be to create a dummy account for each user, where they do not know the password. Make it relate to their windows login, so domain\myname becomes domain\mynamehidden. Then use this to connect to the directory.
This will ensure everything can be audited nicely too.
Look at FileSystemWatcher - it doesn't prevent from changes in directory, but allows to notify program about changes in dir.