Jaseman

We develop commercial software for Windows users in VB.NET. We have a product that we developed in VB.NET 2003 and users run in mainly on Windows XP. When we install the application we also use the default install directory in program files to install a database of lookup information that is used by the application and can be updated by downloading update files from the web. The application also creates a number of xml configuration files in this directory for storing application settings that can be configured, license details and also units they can buy to spend in the application.

We are now porting the application to .NET 2 and ensuring it is also Vista compliant. The effect of this is ensuring it still work for a standard user account in Vista. This is giving us some problems as a user does not have write access to the files we would have put in program files.

We can get around some settings by making them user settings rather than application settings and using the new Studio 2005 settings for user scope. The problem is with the database we installed in program files that periodically needs updating and also application settings like license and units.

Looking in the My.Computer.FileSystem.SpecialDirectories namespace we do have access to AllUsersApplicationData. The problem with writing files to here is that they are read only, and the database is installed with the application. If we leave the database in the install directory users cannot update it and if they buy units and save these to this folder, another user on the same machine cannot modify this file.

The only options we seem to have is to put everything in the users settings, but this means having multiple databases etc for each user, and as the directory uses the version number, they will get a database for each version installed. The other option is to leave the database etc in the install directory or application settings directory but change user rights to that directory to have write access.

What is the preferred method for dealing with these shared files and security issues with a .NET application in Vista Any advice would be greatly appreciated.

Jason



Re: Visual Basic Language Application settings and security

Derek Smyth

Hi Jason,

Have you thought about using Isolated Storage

Give you more than that, it's a storage place that has higher permissions that normal file locations (even Internet users can save there). It has both read and write access regardless of the user account and can have various scope inc. User and Assembly. Don't know how you'd make your database run from here but your settings files, no problem. You seem like a fairly self reliant developer so have a search of MSDN and you'll get some more information on how to use it. Need any more info give me a shout.






Re: Visual Basic Language Application settings and security

Jaseman

After a quick search on MSDN and google it seems to be a storage mechanism that provides standarized ways of associating code with saved data.

On a file party site it suggests the isolated storage file is restricted to the user who created the file. So in a way this is similar to using the .NET settings at user scope.

I also looked on MSDN and it showed the default location on Windows XP it showed:

<SYSTEMDRIVE>\Documents and Settings\<user>\Local Settings\Application Data

They also suggest that if an application is storing lots of settings for a number of users it is common practise to store this data in an application database. So if I did have an application database, or indeed with the lookup database we install currently with the application, a standard user will have read only access if we put it in program files or on Vista program data.

On Vista there is a public folder on C:\Users which we could used, but there is not a managed special folders enum in .NET to access this. We could write a function to get the local users folder, and edit the string to change the location, picking up the right structure for the current operating system. There just doesn't seem to be a preferred way of doing this and Microsoft don't seem to suggest where you would store an application settings database where all users could change it.





Re: Visual Basic Language Application settings and security

Derek Smyth

Hi,

No you can associate storage based on the assembly as well as the user. Still though I don't think it addresses your problem of your database. It was just a thought, it didn't need to be correct (from my point of view).

The other option I was going to post was the path as specified by the Application.CommonAppDataPath property.

C:\Documents and Settings\All Users\Application Data\Company\Application\1.0.0.0

Depends on the application name and version. I had a look at the user permissions on my machine (XP) and although the users do not have write permissions to the All Users directory they do have read & execute and write access to the directory.






Re: Visual Basic Language Application settings and security

Jaseman

On XP we don't have the rights issue, it only becomes a problem with Vista.

On Vista that path is: C:\ProgramData\Company\Application\Version

With Vista all users do not have write permissions to that directory, even at version folder.





Re: Visual Basic Language Application settings and security

Derek Smyth

Well that is just wrong!!

I'd consider that a bug... what about all the applications that have been developed using that path, does that mean they will all stop working. Thats a bug man, thats just wrong.

Sorry I've wasted your time mate as I'm out of options.

I'll make a post pointing to this post asking for someone else to look at it. That way it will appear in the unanswered list and maybe someone else will see it there and can pick this up.






Re: Visual Basic Language Application settings and security

nobugz

It is wrong, you should have write access to the Application.CommonAppDataPath folder. A classic mistake is to forget to put the backslash between the path and the filename.





Re: Visual Basic Language Application settings and security

rkimble

Have you tried using the CommonApplicationData folder Consider this example:

Code Snippet

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

Dim file As String

file = System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)

file = System.IO.Path.Combine(file, "MyApplicationName")

If Not System.IO.Directory.Exists(file) Then

System.IO.Directory.CreateDirectory(file)

End If

file = System.IO.Path.Combine(file, "testsettings.txt")

FileIO.FileSystem.WriteAllText(file, "hello world", False)

file = FileIO.FileSystem.ReadAllText(file)

Me.Text = file

End Sub

So this creates a new directory for the application, writes out a new file, and then reads it. After executing the program once, commenting out the line to write the file still results in the text being loaded. And since this location is based on applications, privelages of the current use should be irrelavent.

I'm using VS05 on a Vista Toshiba Tablet, using the default user account that was created during initial setup - no modifications.






Re: Visual Basic Language Application settings and security

Jaseman

The current user can create a file in the ProgramData directory and subsequently have write access to it. The problem is when another user logs into the same PC using a different profile they have read only access to the file.

So this gives no benefit over using the users own profile, other than other users can read the settings or database. But with my example and how Microsoft suggests using a database to store application settings, only the user who created the database has write access.




Re: Visual Basic Language Application settings and security

Jaseman

It does seem to be a major issue when porting applications to Vista, certainly giving me a headache at the moment.

It won't break the application if only used by one user, but when there is more than one profile on the same PC, it causes major issues.

Thanks for all your feedback anyway, it will be useful to see if you get any further advice from another thread.

Cheers

Jason




Re: Visual Basic Language Application settings and security

rkimble

Not ProgramData - CommonApplicationData:

System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)

I've verified that the code posted works across user accounts.

I compiled the above program with the write file line commented out. After running it once, I created a new standard user profile. I switched accounts and ran the app. The existing file was read successfully. returned to my main profile, un commented the write line and modified the text, then recompiled. I switched back to the new account. I ran the application and the modified text was displayed.

So, using this file location, your application can read and write to files no matter which user account launches the app.






Re: Visual Basic Language Application settings and security

Dave Williamson

There is a disconnect somewhere. I too am interested in using a common directory for my application that all users have access to create, read, and write too. Thus why I followed this thread.

My application does use the CommonApplicationData directory on Windows XP SP2 but the default security only gives read and execute rights to the members of the Users group on the local machine.

I manually did a test by creating 2 users in Windows XP and tried to manually open and save a notepad file using both user accounts. Both user accounts could not save the file. (C:\Documents and Settings\All Users\Application Data\test.txt)

Thus the disconnect from what I am reading and what a default Windows XP SP2 install in virtual PC shows.

To my knowledge there is not a single place on a Windows XP SP2 machine (i assume Vista as well) that allows create, read, and write access for all local machine users.

What am I missing




Re: Visual Basic Language Application settings and security

nobugz

That's not the way it is setup on my PC (XP SP2). When I check the effective permissions for the "Users" group in c:\documents and settings\all users\application data, I see "Create File/Write Data" and "Create Folder" permissions for any folder there, all inherited from the application data folder.





Re: Visual Basic Language Application settings and security

Dave Williamson

I see the same thing WHEN logged in as an administrator on the local machine. If I login as the basic user account the effective permissions for the Users group only shows


Traverse Folder/Execute File
List Folder/Read Data
Read Attributes
Read Extended Attributes
Read Permissions

All other rights are unchecked.

The user account can open the text file with notepad but not save it. The user account can save it by giving it a new name but not by saving over the existing file.

Now I am scratching my head a little more.




Re: Visual Basic Language Application settings and security

rkimble

Dave Williamson wrote:
There is a disconnect somewhere. I too am interested in using a common directory for my application that all users have access to create, read, and write too. Thus why I followed this thread.

My application does use the CommonApplicationData directory on Windows XP SP2 but the default security only gives read and execute rights to the members of the Users group on the local machine.

I manually did a test by creating 2 users in Windows XP and tried to manually open and save a notepad file using both user accounts. Both user accounts could not save the file. (C:\Documents and Settings\All Users\Application Data\test.txt)

Thus the disconnect from what I am reading and what a default Windows XP SP2 install in virtual PC shows.

To my knowledge there is not a single place on a Windows XP SP2 machine (i assume Vista as well) that allows create, read, and write access for all local machine users.

What am I missing

This thread was related to Vista, and in Vista the special folder CommonApplicationData does not point to C:\Documents and Settings\All Users\Application Data! It points to C:\ProgramData which has an entirely different set of permissions. I can't check it at the moment as I don't have access to a XP development machie, but you should really check the result of GetFolderPath(CommonApplicationData) and see what path is returned.