Steve Foster said:
Exactly, so what happens if a user on XP is not a local administrator? I'm
willing to bet that your application fails, and probably in exactly the
same fashion as with Vista.
Yet with over 35,000 users I hardly ever hear from a user who is having
access rights issues. My product is a consumer product that 9 times out of
10 is used on a computer the user owns. For those who install it to a work
PC reports of these problems are very very rare. So clearly Vista is
different since now everyone is having these problems.
If your application was deployed in any organisation where I run the
network, the users would most certainly *not* be local administrators
(it's simply bad practice). Assuming or expecting users to have
administrative privileges is extremely poor practice (though common!).
Expecting my users to have administrative access to theirs PCs is not a poor
practice since it isn't an application that people would install on an
company PC. If expecting an application to be able to write to it's
installation folder is "extremely poor practice" then I suppose you are
right. I need to bow to Microsoft's ridiculous limitations. I'm yet to
hear a good reason why an application should not be permitted to write to
its installation folder other than because Microsoft decided that is a bad
practice.
It's callled the Principle of Least Privilege. Security 101. You don't
give users more privileges than they need without good reason.
You are mis-stating the principal. The PLP "requires that each subject in a
system be granted the most restrictive set of privileges (or lowest
clearance) needed for the performance of authorized tasks. The application
of this principle limits the damage that can result from accident, error, or
unauthorized use."
(
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/luawinxp.mspx).
Since there are applications that have valid reasons for writing to the
installation folder and there is no compelling reason to prevent them from
doing so the practice reasonably falls within the parameter of "needed for
the performance of authorized tasks".
Once again, you don't bind the hands of users without *reason*. The
reasoning "Well *I* can't think of a reason why the user would need to do
that so in the absense of any reason why they *shouldn't* be able to do so
I'll restrict them anyway based on a blind application of the PLP." Being
able to write to an application's installation folder used to be a standard
for Windows. There was no security related reason I can think of for for
changing that standard. In the absense of a good reason for causing
problems with existing software Microsoft has done so anyway.
You wouldn't routinely give employees access to absolutely everything in
an office, would you? Why should the computer be any different?
Do you lock each and every door in your building 24/7? I mean, you wouldn't
routinely give employees access to absolutely every room in an office
building, would you? No? Then by your reasoning you must keep every single
door locked and issue keys only to those who have a reason to go through the
doors. I've never worked in such a corporate environment. Where I have
worked there were rooms that had reasons to be locked and those that didn't.
The ones that needed to be kept locked were kept locked. That's a sensible
application of security. Why should the computer be any different?
