Re: Creating directories on Vista machines using .NET

On Mon, 14 May 2007 08:34:02 -0700, Steve Barker <stevebarker@xxxxxxxxxxxxx> wrote:

Hi guys,

Thanks for your first class assistance everyone!

It feels a little like I’ve opened a can of worms here, and from my point of view, I’m not sure how to proceed.

Yup, you have opened a can of worms. :) But as you've noticed, there's plenty of people here happy to tell you how they think you should write your program. :)

The reason for my original question is that I’ve written a .NET application that installs to the Program Files directory.

Okay so far. :)

The application interacts with
Access databases installed into folders below the folder where the .NET
executable is installed. These databases are used to store essential
application settings; these settings are extremely dynamic in nature. I use the System.Data.OleDb namespace to interact with these databases. My
installer has been created using the installer project in Visual Studio.

You've already strayed a bit here. :) It is not at all clear to me that using an Access database to maintain application settings is the right approach. There are a number of relatively standard methods for maintaining application settings, none of which involve an Access database, nor storing the settings under the Program Files directory hierarchy.

If I install the application to the program files folder on an XP machine, under a non-administrative account, I get all sorts of
problems, the first of which being an MDAC error. This is the case
even if I run the install using administrator rights, having logged
on as a normal user.

Here, I think you should be more clear about exactly what problems occurs, at what stage, and exactly how you are doing things.

For example, what do you mean by "using administrator rights, having logged on as a normal user"? Under XP, not using an administrator account, the usual way to run a program with "administrator rights" is to use the "Run As..." menu command from the right-click menu. Doing this will run the program as if you had logged in as an administrator (assuming you select an administrator account of course), but you will only have administrator rights during that execution session.

This means that if you run the setup as an administrator, you should not get any errors that you would not get having logged in as an administrator directly, *while the setup is running*. But once setup is done, you're back to being a non-administrator user and all the same security restrictions apply.

If you can run setup as an administrator account without getting an MDAC error, then I don't see any obvious reason you should get that error running the setup under the same administrator account using the "Run As..." command. That means that absent any more detailed explanation, I can only assume that the errors you're getting happen either because you aren't actually running "using administrator rights", at least not at the moment that the error happens.

There are literally loads of applications out there that run without problem under a normal user account, and still manage to create folders under their main folder. This is the case with most modern games. However, I have
realised that the default install location for most games is to put them at C:\ level, completely ignoring the Program Files directory. It would seem
that games manufacturers have come to the conclusion that the only way to be sure their applications can do all they need to without getting security
problems is to forget about the program files folder altogether.

Your impression of what happens with "modern games" is incorrect. It is true that lots of applications run without problem under a normal user account. But they do so by following the rules, and not looking for write access to the Program Files directory during normal execution.

It is also true that some applications bypass the security model by installing to the root directory. However, any "modern application" that does this is not following the rules and is likely to break when users do something it doesn't expect, even if the user is within their rights to do so. This includes changing the permissions of the root directory to prevent non-administrator accounts from having write access, as well as changing from the default installation directory to one under the Program Files tree.

A correctly designed application (game or otherwise), will install into the appropriate applications path (generally this is "C:\Program Files", but this is user-configurable and the setup program should respect the user configuration). It will *not* write to that installation path under normal circumstances. If it does need to write to the installation path (for example, the application supports some kind of automatic update mechanism), it will require being run as an administrator or will prompt the user to provide administrator credentials.

It is true that a number of applications exist that do not follow this model, games being particularly bad offenders. But that doesn't make it the right thing to do, and any game that doesn't follow the model introduces a variety of problems (one of the most common being the assumption that only one user will ever run the application, and that user will always be an administrator).

For the record, I have installed a number of recently published games that follow a correct user rights model, installing under "Program Files" and requiring administrator access rights only for administrator-type actions (such as updating the game). Granted, I've also installed a number of recently published games that don't, but that doesn't make it correct behavior. It just means those games aren't doing it right.

I have made a version of my application that also installs into a folder
directly on the root of the C: drive, and it operates without errors
regardless of the user level. I’m hence considering this as a viable way to release my applications in future, since all of them will probably involve significant interactions with local Access databases.

Bad idea. Sorry...you asked. :)

Are there any implications to doing this do you think, or am I just being
lazy and dodging the security problem completely? Would this approach allow my application to be used as a gateway by hackers, or will the signing of the .NET DLLs prevent them from being tampered with? The suggestion of installing static files to the program files directory and Access data files to user
specific folder is not viable in my case, since different users need to be able to share data in these databases.

See above for some examples of problems that might be caused. In addition, you are right to have concerns about the security implications. I don't think you should rely on the .NET signing to protect your application from attacks from hackers. Granted complete access to the entire installation tree, there may be ways to work around that signing.

If you absolutely *must* store your application settings in Access databases, the "right way" to do it is to keep those databases under the "All Users\Local Settings" directory tree. This directory tree should be accessible by all users, and doesn't require that those users have write access to where the code for your application resides.

Ideally, you would not have application settings that when changed by one user would affect other users. Frankly, it's just not a good idea generally. I can't rule out the possibility that you have one of those rare instances where it makes sense, but just as it seems unlikely to be that an Access database is the right way to store the settings, it also seems unlikely to me that having any non-administrator user on the computer being able to change settings in a way that affects other users is the correct model.

But if you must do it this way, the "All Users\Local Settings" directory is the place to do it.

Pete
.

Relevant Pages

  • Re: Creating directories on Vista machines using .NET
    ... application that installs to the Program Files directory. ... For example, what do you mean by "using administrator rights, having ... This is the case with most modern games. ... It will *not* write to that installation path under ...
    (microsoft.public.dotnet.framework)
  • Re: Problems installing SQL Server 2005 in two node cluster
    ... I'm assuming that SQL Server 2005 doesn't need to be an administrator ... that make sure you are not using domain admin-level accounts for the service ... Server2005Setup Log Files" and "StartingSQLServerManually." ... This is the fifth attempt at installation, ...
    (microsoft.public.sqlserver.clustering)
  • Re: What will happen after this senario?
    ... > "ABC" user who member windows administrator group. ... Which flies in the face of convention, intuitive installation and the ... will know this ABC user is the Oracle software ...
    (comp.databases.oracle.server)
  • Re: Cant Install Printer Software -- Wont Recognize System Admin
    ... Are you running printer installation software from HP? ... shouldn't be checking to see if you are the built-in administrator account, ... Have you tried the "Add Hardware" wizard in the Control Panel to install ... > you can't install software in Safe mode (at least I ...
    (microsoft.public.windowsxp.security_admin)
  • Re: SQL 2005 Tools Installation Location
    ... this is expected behavior with SQL Server Tools installation. ... installed to the Program Files directory. ... assemblies that are installed to the Global Assembly Cache, ...
    (microsoft.public.sqlserver.setup)