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
