Very troubling problems running on Vista Beta

[Dan]

Why should the application have the privilege of writing to its' own
folder?

Why shouldn't it? You need to have a good reason to take something away
that was previously allowed. What's the good reason?

Users should not generally have privileges to write to installation
folders only their own profile space.

Why shouldn't they? Again, you need a good reason before you take something
away from the user.

 

[Dan]

Then why not set the ACLs accordingly during installation - 99% of
applications that want to write to their own folder don't do this, they
simply expect that users would be local administrators (and indeed if you
call Tech Support the response is "oh yes, make users local
administrators").

It's this abject failure on the part of developers that UAP is trying to
help with.

When the user installs my app they are given the option to give either just
their user account access to the software being installed or "any user on
this machine" (I'm using Install Shield to build my setup). Yet regardless
of which the user selects the app can't write to the installation folder
when running on Vista. And that's the developer's (i.e. my) fault?

 

[Dan]

Well, applications saving user-specific information in the application
folder is also a stupid idea. That's what the users profile folder space
is for.

Then applications storing application specific information in the
application folder must be a stupid idea too since that isn't being allowed
either. Somehow the idea doesn't strike me as stupid. Scattering
application related files to various locations on the hard drive when they
could just as easily be stored in the application folder strikes me as
stupid.

Really, this concept is not new - it's been around since NT4 and probably
even NT3. In a sense, it would almost be better simply to fail the writes,
except that application vendors would carry on with the current lazy
answer "make your users local administrators", rather than getting with
the program and making their applications well-behaved. At least MS are
trying to provide a graceful (ish) solution that lets applications work,
without forcing the administrative privilege escalation.

It isn't graceful(ish). It's a creator of confusion. I don't find
confusion graceful at all. If an app tries to write to the installation
folder than let it do so or don't let it. But don't trick it and the user
into *thinking* the write worked when in fact it did not.

 

[Dan]

I expect that you use HKLM to store user information too, rather than HKCU
when using the registry, right?

No, I don't. What's your point? That saving non-user related application
data in the application folder is comparable to storing user specific
information in the local machine node of the Registry? How's that?

 

[Steve Foster [SBS MVP]]

Why shouldn't it? You need to have a good reason to take something away
that was previously allowed. What's the good reason?

It's not allowed now, unless the user is a local administrator.

What's the good reason for allowing it? Users are supposed to be running
applications, not installing them. Administrators install applications.

Why shouldn't they? Again, you need a good reason before you take
something away from the user.

It's not being taken away, ordinary users do not have privilieges to write
to applications installation folders now. The question is why should an
ordinary user have privileges to write to application installation folders?

 

[Steve Foster [SBS MVP]]

When the user installs my app they are given the option to give either
just their user account access to the software being installed or "any
user on this machine" (I'm using Install Shield to build my setup). Yet
regardless of which the user selects the app can't write to the
installation folder when running on Vista. And that's the developer's
(i.e. my) fault?

They probably can't in XP either, if the user is not a local administrator.

It's down to you (or InstallShield) to set ACLs appropriately if you
really need an ordinary user to be able to modify the application
installation.

Of course, the question then should be "why does an ordinary user need to
modify the application installation?"

 

[Steve Foster [SBS MVP]]

Then applications storing application specific information in the
application folder must be a stupid idea too since that isn't being
allowed either. Somehow the idea doesn't strike me as stupid. Scattering
application related files to various locations on the hard drive when they
could just as easily be stored in the application folder strikes me as
stupid.

Wouldn't this information be written at installation time, when the
administrator credentials would support writing to the application
installation?

If it's really necessary for an ordinary user to be making global changes
that will affect other users (which is your implication), then set the
ACLs accordingly during installation to allow ordinary users write
privileges. Don't rely on them being granted wide-ranging administrative
privileges (which is not a wise assumption).

It isn't graceful(ish). It's a creator of confusion. I don't find
confusion graceful at all. If an app tries to write to the installation
folder than let it do so or don't let it. But don't trick it and the user
into thinking the write worked when in fact it did not.

That's the point - the write succeeds. And the application gets to read
back what it wrote, exactly as expected. And yet the application
installation is protected. Of course, application-specific changes that
would impinge on other users don't get seen by them - effectively each
user now gets their own set of global settings (but then, that comes back
to should users be changing global settings that affect other users -
isn't that work for administrators).

As fas as I can tell, if your application runs into trouble on Vista
because of UAP, it probably runs into trouble on XP if the user is not a
local administrator too. Do your applications run properly on XP without
administrative privileges?

Have you come across http://www.threatcode.com ?

 

[Steve Foster [SBS MVP]]

No, I don't. What's your point? That saving non-user related application
data in the application folder is comparable to storing user specific
information in the local machine node of the Registry? How's that?

Oh, it was really meant as a light-hearted rejoinder - you already have
the position that ordinary users don't have the necessary privileges to
write to an application's installation folder (unless the ACLs were set to
allow it during installation), and that's been the case since the early NT
days. Only the Win9x line allowed free rein (and that line ended some 5
years ago) since there was no security in Win9x.

 

[Dan]

They probably can't in XP either, if the user is not a local
administrator.

They almost always are a local administrator. I have a very large user base
and almost never have reports of a problem in this area with XP users. But
every Vista beta tester who tested my app had this same problem.

It's down to you (or InstallShield) to set ACLs appropriately if you
really need an ordinary user to be able to modify the application
installation.

Of course, the question then should be "why does an ordinary user need to
modify the application installation?"

To update the software when an update is available. That is a fairly
standard option in software today. Lots of software products have a "Check
for program updates" option under their Tools or Help menus. And when a new
free update is available the user is offered to automatically update. My
anti-virus application does this frequently (not only virus definitions
updates but also updates to the base application).

I have to wonder about this "why does the ordinary user need to..." line of
reasoning. The real question is why the ordinary user should NOT be allowed
to do it, not why they should. You don't take access away from a user
without an explicit reason for doing so.

 

[Chris Altmann]

A possible solution for the update problem. Download your update as a msi or
a setup.exe to your AppData folder then run it. I think Vista should then
ask for admin rights at that point and your msi can do the update.

 

[Dan]

A possible solution for the update problem. Download your update as a msi
or a setup.exe to your AppData folder then run it. I think Vista should
then ask for admin rights at that point and your msi can do the update.

I've had another developer recommend that I add a manifest to my updater
utility stating that it requires admin access. The user will get a warning
asking whether or not to grant the app access every time it runs (which
would only be when an update was being performed) and if they user says OK
then it will work as it presently does now on all other Windows systems.
I'm not thrilled with my users having to get past an OS warning but it looks
like I'll have to go that route.

 

[Steve Foster [SBS MVP]]

They almost always are a local administrator. I have a very large user
base and almost never have reports of a problem in this area with XP
users. But every Vista beta tester who tested my app had this same
problem.

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.

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!).

To update the software when an update is available. That is a fairly
standard option in software today. Lots of software products have a
"Check for program updates" option under their Tools or Help menus. And
when a new free update is available the user is offered to automatically
update. My anti-virus application does this frequently (not only virus
definitions updates but also updates to the base application).

I have to wonder about this "why does the ordinary user need to..." line
of reasoning. The real question is why the ordinary user should NOT be
allowed to do it, not why they should. You don't take access away from a
user without an explicit reason for doing so.

It's callled the Principle of Least Privilege. Security 101. You don't
give users more privileges than they need without good reason.

You wouldn't routinely give employees access to absolutely everything in
an office, would you? Why should the computer be any different?

 

[Dan]

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?