Oren Kravetz Reporter
	Description • 17 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1

When trying to install Firefox 3 Beta 1 under a Standard User in Windows Vista, upon getting to the "Choose Install Location" section of the installer, clicking "Next" gives the error that "You don't have access to write to the installation directory.  Click OK to select a different directory."  If I right-click the installer and choose "Run as Administrator" and enter the appropriate credentials, it installs just fine.  On a similar note, the installer did not ask to be elevated as most installers for Vista do by now.

Reproducible: Always

Steps to Reproduce:
1. Login to Windows Vista under a Standard User Account.
2. Download the Firefox 3 Beta 1 installer.
3. Run the installer.
4. Proceed through the installer until the "Choose Install Location" dialog.
5. Click "Next" to accept the default directory.
Actual Results:  
A popup dialog exclaims:
"You don't have access to write to the installation directory.  Click OK to select a different directory."

Expected Results:  
The installer should have asked for elevated rights upon execution and run the installer as such.

	Marco Bonardo [:mak]
	Comment 1 • 17 years ago

what folder are you trying to install to?

	Oren Kravetz Reporter
	Comment 2 • 17 years ago

The default folder, "C:\Program Files\Mozilla Firefox 3 Beta 1\"

	Robert Strong (they/them - no direct email) Assignee
	Comment 3 • 17 years ago

The default accounts on Vista are members of the admin group and since you are installing as a standard user the account cannot be elevated. You can do one of the following:

a) install with an account that is a member of the admin group.

b) right click the installer and select Run as Administrator (this will display the prompt). You won't be able to run the app at the end of the installer as your user account since you will be running the installer with different credentials. No one has been able to come up with a workaround to this issue.

c) install into a location where your account has write privileges.

We could display the "run as" version of UAC for this scenario and if they click cancel continue the install as a standard user requiring them to select a location where they have write access since they should be able to install as well. I don't care much for this since we would either have to remove the launch and end of install or have people using non-default accounts reporting bugs about item b) above. There really isn't a decent solution for the non-default account scenario.

	Oren Kravetz Reporter
	Comment 4 • 17 years ago

Every other installer, however, including the one for Fx2, prompts for elevated rights.  Even when running as an Administrator Account, installers bring up the password-less UAC prompt.  In fact, even Administrator Accounts run as Standard Users most of the time and elevate themselves when needed--using the password-less prompt when necessary.

Also, Vista is supposed to recognized installers on its own as seen here: 

http://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-422c-b70e-b18ff918c2811033.mspx?mfr=true
(scroll to where it reads "Installer Detection Technology")

So basically, I guess the bug is that the new Fx3b1 installer isn't being recognized as such by Vista.

	Robert Strong (they/them - no direct email) Assignee
	Comment 5 • 17 years ago

(In reply to comment #4)
> Every other installer, however, including the one for Fx2, prompts for elevated
> rights.
I'd like to investigate this... can you provide a couple of examples?

> Even when running as an Administrator Account, installers bring up the
> password-less UAC prompt.  In fact, even Administrator Accounts run as Standard
> Users most of the time and elevate themselves when needed--using the
> password-less prompt when necessary.
This has nothing to do with this bug because the Firefox installer does indeed bring up the UAC prompt for "Adminstrator Accounts".

> Also, Vista is supposed to recognized installers on its own as seen here: 
> 
> http://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-422c-b70e-b18ff918c2811033.mspx?mfr=true
> (scroll to where it reads "Installer Detection Technology")
That is for backwards compatibility and prevents users that are not running as a default Vista account and don't know an administrator password from installing.

> So basically, I guess the bug is that the new Fx3b1 installer isn't being
> recognized as such by Vista.
What about the person that is not running as a default Vista account and doesn't know an administrator password? This seems much more likely to occur than your scenario... someone using a locked down system for example.

	Robert Strong (they/them - no direct email) Assignee
	Comment 6 • 17 years ago

To clarify, we chose an implementation that allowed a user account that was not a member of the administrators group to install as that user or they can select "Run as Administrator" to install with a privileged account and a user that was a member of the administrators group to install elevated. Previously a user account that was not a member of the administrators group could not install at all.

Considering that MS is recommending (at the very least they are doing so by making the default account created during install a member of the administrators group though I haven't looked for or seen any articles stating this) that the account people use is an account that is a member of the administrators group this seems like the best option available given the options provided by Vista. Yes, there will be some people that choose to use an account that is not a member of the administrators group and they will no longer receive the UAC "run as" prompt. There will also be people that are not a member of the administrators group and don't know an administrator account password that can now install the application.

	Robert Strong (they/them - no direct email) Assignee
	Comment 7 • 17 years ago

(In reply to comment #6)
> To clarify, we chose an implementation that allowed a user account that was not
> a member of the administrators group to install as that user or they can select
> "Run as Administrator" to install with a privileged account and a user that was
> a member of the administrators group to install elevated. Previously a user
> account that was not a member of the administrators group could not install at
> all.
unless they knew an administrator account's password.

	Oren Kravetz Reporter
	Comment 8 • 17 years ago

What I don't understand is what changed between the Fx2 installer and the Fx3 installer.  Also, you're still allowing Fx3 to be installed by a Standard User without an Administrator password (if they change the install path to one they own), which is the whole thing the UAC is trying to avoid in the first place.
  
I'll grant you that most Vista users are not aware of the Standard User option, and therefore use Administrator Group accounts.  However, even so, if an Administrative user installs Fx3 in its present form, they won't even see the UAC consent prompt upon installation.  They suggestions for installing in Comment #3 are fine and all, but the "standard" Standard User (if you'll excuse the expression) won't know about the "Run as Admin" option, IMHO, much less find this bug and follow the instructions.  If they take the alternate route and have to get an Administrator to log in and then install it for them...then you're just doing the same thing the UAC is doing, but making it more difficult.  If they have to get the Administrator anyway, he/she can then enter their password into the UAC prompt to allow the installation.

I just don't see why the installer can't be made to have the same specifications as Fx2's did that cause Vista to automatically prompt the user for permission to install a program.  I can see how an Administrative User would like to avoid the UAC prompt altogether...and would therefore consider this a feature, not a bug.  However, for those Standard Users (which every knowledgeable person using Vista should be, though of course isn't) you're just making things more difficult.  Just curious...what exactly would it involve to find/make the changes to the installer?

Also, you asked for an example, and once again, I offer you Fx2.0.09 as the example. Just tested it myself.

Oh, and I apologize for the rant, but I didn't think this was going to be such a big deal and I'm just trying to defend my case, until proven otherwise.  Keep up the great work on a stupendous product though.  Whichever way this goes, it won't keep me from using Firefox.

	Robert Strong (they/them - no direct email) Assignee
	Comment 9 • 17 years ago

(In reply to comment #8)
> What I don't understand is what changed between the Fx2 installer and the Fx3
> installer.  Also, you're still allowing Fx3 to be installed by a Standard User
> without an Administrator password (if they change the install path to one they
> own), which is the whole thing the UAC is trying to avoid in the first place.
What changed as it relates to the bug you filed is that a non Admin group user can install the app without knowing the username / password for a user in the admin group.

Also, what you stated as the reason for the UAC is not the reason for it from what I have read whatsoever. Can you provide a link that states that is the reason?
 
> I'll grant you that most Vista users are not aware of the Standard User option,
> and therefore use Administrator Group accounts.  However, even so, if an
> Administrative user installs Fx3 in its present form, they won't even see the
> UAC consent prompt upon installation.
Please try it out with UAC turned on. They do in fact get the UAC prompt.

> They suggestions for installing in
> Comment #3 are fine and all, but the "standard" Standard User (if you'll excuse
> the expression) won't know about the "Run as Admin" option, IMHO, much less
> find this bug and follow the instructions.  If they take the alternate route
> and have to get an Administrator to log in and then install it for them...then
> you're just doing the same thing the UAC is doing, but making it more
> difficult.  If they have to get the Administrator anyway, he/she can then enter
> their password into the UAC prompt to allow the installation.
We are considering changing it for the few people that don't know.

> I just don't see why the installer can't be made to have the same
> specifications as Fx2's did that cause Vista to automatically prompt the user
> for permission to install a program.  I can see how an Administrative User
> would like to avoid the UAC prompt altogether...and would therefore consider
> this a feature, not a bug.  However, for those Standard Users (which every
> knowledgeable person using Vista should be, though of course isn't) you're just
> making things more difficult.  Just curious...what exactly would it involve to
> find/make the changes to the installer?
Because as stated above and in at least one previous comment... a non Admin group user that doesn't know the username / password of another account that is a member of the Admin group will not be able to install (e.g. a locked down system such as in a library, etc.).

> Also, you asked for an example, and once again, I offer you Fx2.0.09 as the
> example. Just tested it myself.
That uses the heuristics provided by the OS for installers that have not been updated to work on Vista and hence is not a valid example of an installer that has been updated so Admin and non Admin group users can install the app.

> Oh, and I apologize for the rant, but I didn't think this was going to be such
> a big deal and I'm just trying to defend my case, until proven otherwise.  Keep
> up the great work on a stupendous product though.  Whichever way this goes, it
> won't keep me from using Firefox.
You are promoting the use case that you use which is entirely understandable. We have to take into account other use cases such as the one where a user is not a member of the Admin group and doesn't know the username / password of a user that is a member of the Admin group.

	Oren Kravetz Reporter
	Comment 10 • 17 years ago

OK.  Fair enough.  As long as you make the installation instructions for the non-Admin user more prominent/easy to find/etc., I guess that makes sense.

Also, I think you contradicted youself. You said:
> What changed as it relates to the bug you filed is that a non Admin group user
> can install the app without knowing the username / password for a user in the
> admin group.
And yet:
> Because as stated above and in at least one previous comment... a non Admin
> group user that doesn't know the username / password of another account that is
> a member of the Admin group will not be able to install (e.g. a locked down
> system such as in a library, etc.).

So, can they or can't they install it?  If so, am I right in assuming that it's to a directory they have write access to?

Third, in response to: 
> Also, what you stated as the reason for the UAC is not the reason for it from
> what I have read whatsoever. Can you provide a link that states that is the
> reason?
"The main goal of User Account Control is to reduce the exposure and attack surface of the operating system by requiring that all users run in standard user mode. This limitation minimizes the ability for users to make changes that could destabilize their computers or inadvertently expose the network to viruses through undetected malware that has infected their computer." (http://technet.microsoft.com/en-us/windowsvista/aa906021.aspx)

	Robert Strong (they/them - no direct email) Assignee
	Comment 11 • 17 years ago

(In reply to comment #10)
>...
> So, can they or can't they install it?  If so, am I right in assuming that it's
> to a directory they have write access to?
That is correct

> Third, in response to: 
> > Also, what you stated as the reason for the UAC is not the reason for it from
> > what I have read whatsoever. Can you provide a link that states that is the
> > reason?
> "The main goal of User Account Control is to reduce the exposure and attack
> surface of the operating system by requiring that all users run in standard
> user mode. This limitation minimizes the ability for users to make changes that
> could destabilize their computers or inadvertently expose the network to
> viruses through undetected malware that has infected their computer."
> (http://technet.microsoft.com/en-us/windowsvista/aa906021.aspx)
And none of this statement is circumvented by allowing a user that is not a member of the admin group from installing. The UAC allows a user that is a member of the admin group to run in "standard user mode" so if anything a user installing without elevating is exposing themselves even less so.

	Robert Strong (they/them - no direct email) Assignee
	Comment 12 • 17 years ago

(In reply to comment #11)
> (In reply to comment #10)
> >...
> > So, can they or can't they install it?  If so, am I right in assuming that it's
> > to a directory they have write access to?
> That is correct
They can in case it isn't clear from the previous comments stating that a user that is not a member of the admin group and doesn't have the username / password of a user that is a member of the admin group and yes, they have manually choose a directory they have write access to in which to install the app.

	Oren Kravetz Reporter
	Comment 13 • 17 years ago

OK.  I guess it's just a case of "It's not a bug, it's a feature."  Should this be closed then?

	Robert Strong (they/them - no direct email) Assignee
	Comment 14 • 17 years ago

nah... we are evaluating whether we are able to change the behavior so it provides what you would like and allow users to install that are not a member of the admin group that don't know a username / password of a member of the admin group.

	Oren Kravetz Reporter
	Comment 15 • 17 years ago

Oh.  OK.  I'll keep an eye out for a decision then.  Also, I didn't realize I actually closed the ticket before--it was an accident.

	Jan Goosen
	Comment 16 • 17 years ago

Folks

Don't know if I should log this as a new bug, but the same problem occurs when installing FF3b5 in WIndows Vista Ultimate.

Steps to reproduce
* Windows Vista Ultimate SP1 running as a Limited User
* Run FF3b5 installer
* Series of windows as follows:
  1. "Do you want to run this file ..."

Happy to submit a new bug if required

Jan
  2. "Welcome to FireFox 3 Beta 5 Setup Wizard ..."
  3. "License Agreement" - I checked 'Accept'
  4. "Setup Type ..." - I selected 'Typical'
  5. "Choose install location ..." - I left it as the default C:\Program
      Files\FireFox Beta 5\
* At this point I selected "Next"
* Message displayed "You don't have access to write to the installation directory. Click ojkay to select a different directory."
* Unable to proceed further and had to quit at this point.

* Able to install successfully by running the install file under elevated privileges:
  1. Right click
  2. "Run as ..."

Expected behaviour: 

(The sequence of events shown above is inconsistent with the usual response from UAC (User Account Control). 
* Double click install file
* Windoes would probably allow the files to unpack
* Shortly after unpack, I would expect the screen to dim and see a prompt "Windows needs your permission to continue"
* I would then enter an administrator's password
* Install would continue uninterrupted by UAC.

	Robert Strong (they/them - no direct email) Assignee
	Comment 17 • 17 years ago

Jan, that is the same as this bug as discussed in the previous comments

	Johannes Rössel
	Comment 19 • 16 years ago

Short note aside, I don't know whether that came up here already: Windows installer (msi) allows that the elevation prompt is only displayed if elevation is actually needed; this usually happens right at the start of the installation process (the progress bar thingie) instead of the installer start-up.

A way to resolve this, that would actually account for both use cases that were covered here (installing as admin on a system you own and installing as limited user on a locked-down system) would be to replicate this behaviour and only ask for elevation if we actually need it (i.e. installing into a folder that is not owned by the installing user). For the case that the user doesn't have the adminstrator password (or wants to install somewhere in his home directory) he can abort the prompt and choose a different installation path instead.

However, the majority of (Windows) users are probably adminstrators on their machines and thus the current solution makes it unnecessary difficult to install FF3 on Vista.

	uamjet602
	Comment 20 • 16 years ago

This problem prevents updates from installing if you're not an administrator, so it's a security problem. The decision that was made in this bug re. installation by a non admin user should be reviewed and in my opinion, reversed.

Non admin users that want to install are a small minority and have an easy workaround: Use the zip files instead of the installer. Mozilla should not sacrifice security for the majority of users (especially those that attempt to run their system securely by running their desktop without administrator privileges) to please the minority.

CC: security@mozilla.org

	Robert Strong (they/them - no direct email) Assignee
	Comment 21 • 16 years ago

(In reply to comment #20)
> This problem prevents updates from installing if you're not an administrator,
> so it's a security problem. The decision that was made in this bug re.
> installation by a non admin user should be reviewed and in my opinion,
> reversed.
The installer does not prevent software update from running. Perhaps you are referring to updating an existing installation using the installer?

> Non admin users that want to install are a small minority and have an easy
> workaround: Use the zip files instead of the installer. Mozilla should not
> sacrifice security for the majority of users (especially those that attempt to
> run their system securely by running their desktop without administrator
> privileges) to please the minority.
Non admin users that know an admin account's password are likely an even smaller minority of users. The majority of users on Vista are likely using UAC as intended (e.g. their account is in the administrators group) which provides the same security as running as a non-admin account with or without UAC turned on. 

The only scenario fixing this bug would solve is when a user account is not a member of the administrators group and UAC is turned on which is not the majority of users or the recommended way to use UAC promoted by MS or anymore secure than running with an account that is a member of the administrators group with UAC turned on. Can you provide any information regarding why it is more secure to use a non admin user account with UAC or information (even anecdotal evidence) as to this being the majority of users?

	uamjet602
	Comment 22 • 16 years ago

I am assuming the software update mechanism uses the same code as the installation, which would seem logical to me, but I could of course be mistaken.

Microsoft advises people, in their security 'Best Practices' documentation, to create non administrator (AKA 'standard') accounts, and expect the system to ask them for an administrator password in case privileges are needed. Quote:

'When a Standard User is using the system and attempts to do something for which they do not have authorization, they will be asked for permission from Windows and require the Administrator account’s password. That prompt is known as a ‘Credential Prompt’ (see Figure 3) because it requires credentials from another account to permit the action and proceed.'

Obviously the system is more secure when security-sensitive operations are more than one click away. The whole idea is to only use privileges when needed.

	Robert Strong (they/them - no direct email) Assignee
	Comment 23 • 16 years ago

Both Software Update and the Installer use the same logic. Software Update needs to know the user can elevate prior to offering an update so we can't just display the UAC's "Run As" prompt as is being requested for the installer in this bug since a standard user won't always know an administrator account and password. Hence, the user would not be notified about updates ( bug 407875 ) as is the case for non admin users on XP, etc.

Also from the article:
In Windows Vista, both Administrators and Standard Users run applications with roughly the same permissions to change their own settings. UAC provides a method of separating standard user privileges and tasks from those that require Administrator access. UAC increases security by enabling you to make Standard User the default user account for everyday use.

So, we only offer updates to those running as admin with or without UAC turned on. In the future after we implement MSI's we will be able to offer updates to both non admin and admin accounts since MSI's provide a facility to update the application for non admin accounts as well as provide a UAC prompt to install. I believe that this will prevent installing as a non-admin user without knowledge of admin credentials but we will try to find a workaround for that at that time (there are several advocates for providing this functionality so kiosk users, etc. can install and use Firefox).

	uamjet602
	Comment 24 • 16 years ago

(In reply to comment #23)
> Both Software Update and the Installer use the same logic. Software Update
> needs to know the user can elevate prior to offering an update so we can't just
> display the UAC's "Run As" prompt as is being requested for the installer in
> this bug since a standard user won't always know an administrator account and
> password.

Administrators that support users that are not administrators can (or should be able to) configure firefox so it doesn't autoupdate (like the distro's do on Linux).

In other programs, if you get an elevation prompt and you enter your own (non-admin) account, the program continues but the operation fails. It's not unreasonable for firefox to then tell the user that he needs more privileges or forgo the operation. At least he'd know that his system is not secure until he figures out how to update.

> Also from the article:
> In Windows Vista, both Administrators and Standard Users run applications with
> roughly the same permissions to change their own settings. UAC provides a
> method of separating standard user privileges and tasks from those that require
> Administrator access. UAC increases security by enabling you to make Standard
> User the default user account for everyday use.
You're arguing my point here. Please take note of this important sentence in the same document, regarding the prompts you get when running as an administrator with UAC on:

'It’s very important to remember that UAC prompts are not a security boundary – they don’t offer direct protection.  They do offer you a chance to verify an action before it happens.'

> 
> So, we only offer updates to those running as admin with or without UAC turned
> on. In the future after we implement MSI's we will be able to offer updates to
> both non admin and admin accounts since MSI's provide a facility to update the
> application for non admin accounts as well as provide a UAC prompt to install.
> I believe that this will prevent installing as a non-admin user without
> knowledge of admin credentials but we will try to find a workaround for that at
> that time (there are several advocates for providing this functionality so
> kiosk users, etc. can install and use Firefox).
> 
Workarounds: Use the zip files, use a fixed install on a thumb drive.

	Robert Strong (they/them - no direct email) Assignee
	Comment 25 • 16 years ago

I'm not arguing the point... just pointing this out as additional info to consider.

The UAC prompt and the UAC "Run As" prompt (which is slightly different than the regular Run As prompt) both fall into the "...offer you a chance to verify
an action before it happens." category.

Keep in mind that using zip files and installing into program files won't provide software update functionality due to (as noted in comment #23):
"Hence, the user would not be notified about updates ( bug 407875 ) as
is the case for non admin users on XP, etc."

It is also important to note that the accounts created when setting up the OS are a member of the Administrators group.

	Daniel Veditz [:dveditz]
	Comment 26 • 16 years ago

Microsoft is pushing people to use standard accounts and would like this scenario to work. Nominating for 3.1, and wanted 3.0.x if possible.

	Robert Strong (they/them - no direct email) Assignee
	Comment 27 • 16 years ago

(In reply to comment #26)
> Microsoft is pushing people to use standard accounts and would like this
> scenario to work. Nominating for 3.1, and wanted 3.0.x if possible.
Taking... should be possible for 3.0.x by prompting to elevate via the UAC while continuing the install if the user doesn't provide credentials so users without admin credentials can still install into a non restricted location.

	Daniel Veditz [:dveditz]
	Comment 28 • 16 years ago

More details from Crispin Cowan, Microsoft PM for the UAC feature, sent to the Mozilla Security alias:

"Our long-term goal is to make all Windows software work well for users running as a Standard User, so that our users can have the security of running without privilege day to day without the hassle of having to elevate for special things.

I tried to install Firefox 3 today on VistaSP1. It fails to install properly as a Standard User. Steps:
  1. Download the Firefox 3 installer http://www.mozilla.com/en-US/products/download.html?product=firefox-3.0&os=win&lang=en-US
  2. Save the file
  3. Run the file
  4. Select Standard install
  5. Firefox proposes to install into C:\Program Files\Mozilla Firefox\
    a. Click Next
  6. Installer errors out, saying “You don’t have access to write to the 
     installation directory. Click OK to select a different directory.”

What the installer should have done was request elevation, which would have presented an OTS (Over The Shoulder) prompt to get the privilege necessary to install in the system directory.

Alternately, the installer could have offered a choice between per-user installation and system-wide installation, noting that one will have to elevate for system wide installation.

This problem appears to be due to the Firefox installer having a manifest that requests “asInvoker” instead of “highestAvailable”, coupled with the file names being such that the Windows installer-detection heuristics are not triggering.

The installer does work if you start it with “run as->administrator”. However, I then hit a second bug, that the installer says that it is going to install Firefox as my default browser, and there are no install options (under Standard or Custom) to turn that off. I want Firefox as an alternate browser, and there appears to be no way to do that in Firefox 3."

	Masatoshi Kimura [:emk]
	Comment 29 • 16 years ago

(In reply to comment #3)
> b) right click the installer and select Run as Administrator (this will display
> the prompt). You won't be able to run the app at the end of the installer as
> your user account since you will be running the installer with different
> credentials. No one has been able to come up with a workaround to this issue.
We could launch the app at the end of the installer as Standard User account because LaunchAsNormalUser borrowed a token from logon user's desktop (that is, Standard User's one). It was broken by a fix for bug 437349.

	Robert Strong (they/them - no direct email) Assignee
	Comment 30 • 16 years ago

(In reply to comment #29)
> (In reply to comment #3)
> > b) right click the installer and select Run as Administrator (this will display
> > the prompt). You won't be able to run the app at the end of the installer as
> > your user account since you will be running the installer with different
> > credentials. No one has been able to come up with a workaround to this issue.
> We could launch the app at the end of the installer as Standard User account
> because LaunchAsNormalUser borrowed a token from logon user's desktop (that is,
> Standard User's one). It was broken by a fix for bug 437349.
We can prompt with the UAC "run as" and if canceled we can continue on with the non admin path. Also, the LaunchAsNormalUser code path caused Bug 386826.

As for launching using the desktop token, are you sure that we get the token for the original user's desktop or for a desktop of the user account specified when using the UAC "run as" prompt?

	Masatoshi Kimura [:emk]
	Comment 31 • 16 years ago

(In reply to comment #30)
> As for launching using the desktop token, are you sure that we get the token
> for the original user's desktop or for a desktop of the user account specified
> when using the UAC "run as" prompt?
I'm confident because the UAC "run as" doesn't create a desktop. It uses the same desktop as logon user's one.

	Robert Strong (they/them - no direct email) Assignee
	Comment 32 • 16 years ago

Even so we can accomplish the same end result as noted in comment #30 without reintroducing bug 386826 or de-elevating an intentional "run as administrator" when the app needs to restart.

	Masatoshi Kimura [:emk]
	Comment 33 • 16 years ago

OK, I have to agree with that. Even if we need de-elevation, it should be implemented in installer to prevent bug 386826 or the app restart issue.

	pyrates18
	Comment 36 • 16 years ago

I experienced the same thing in Windows 7.  We shouldn't rely on Microsoft to detect if the firefox installer is an installer, the installer should be smart enough to know that already.  So I propose this:

1.  Launch installer and show 2 options.  Install for all users and install for your user.  It will default to Install for all users of course.
2.  If you select install for all users, it prompts for admin elevation no matter if you're a regular user or an admin user running as a regular user the way windows 7 and vista does it.  It will then install in the normal place where it usually does and in the all users start menu.
3.  If you select install for your user only, then it will change the install location to your local users folder where other apps can be installed and in your start menu only.  Vista and windows 7 do allow for this.

This I think will satisfy everyone who wants to install it for all users or just their user.  What do you all think?

	Robert Strong (they/them - no direct email) Assignee
	Comment 37 • 15 years ago

Phil and Frank, just a heads up that this will likely get fixed on the 1.9.1 branch after Firefox beta 4. I'll be sure to file followup bugs for Thunderbird and SeaMonkey if necessary along with patches since the changes to apps will be minimal.

	Robert Strong (they/them - no direct email) Assignee
	Comment 38 • 15 years ago

FYI: this is turning out to be a much larger change than I originally thought it would be. For example, when elevated it now needs to use the UAC Plugin IPC to the unelevated process when creating shortcuts.

Though I am not thrilled with all of the additional complexity this is introducing it has been a goal to never prevent installing for a non admin user that doesn't know admin credentials. meh

	Robert Strong (they/them - no direct email) Assignee
	Comment 41 • 15 years ago

Comment on attachment 378456 [details] [diff] [review]
patch rev1

With this patch on Vista and above:
a) elevation is requested but not required for standard users.
b) elevation is requested and required for users that are a member of the administrators group.

The two defines are used so apps can opt-in to the new behavior and so this patch won't break them.

This also tries to find a decent install location instead of asking the user to select one since that has been confusing per the install survey.

	Jim Mathies [:jimm]
	Comment 42 • 15 years ago

For completeness sake, maybe fire up a try build we could take for a spin? This all looks fine to me.

	Robert Strong (they/them - no direct email) Assignee
	Comment 43 • 15 years ago

Submitted the patch to the try server

	Robert Strong (they/them - no direct email) Assignee
	Comment 44 • 15 years ago

Resubmitted since mozilla-central decided to burn due to a bad checkin

	Robert Strong (they/them - no direct email) Assignee
	Comment 45 • 15 years ago

try build
https://build.mozilla.org/tryserver-builds/rstrong@mozilla.com-404541-installer2/install/sea/404541-installer2-win32.installer.exe

	Jim Mathies [:jimm]
	Comment 46 • 15 years ago

Everything seemed to be working - the install went through and defaults worked. Except there was no uninstall option in add/remove. Was that expected?

	Robert Strong (they/them - no direct email) Assignee
	Comment 47 • 15 years ago

I have one named "Minefield (3.6a1pre)" whether I install with elevation or without as a standard user. Can you check again and also check if there is an entry under HKLM or HKCU  Software\Microsoft\Windows\CurrentVersion\Uninstall?

	Jim Mathies [:jimm]
	Comment 48 • 15 years ago

(In reply to comment #47)
> I have one named "Minefield (3.6a1pre)" whether I install with elevation or
> without as a standard user. Can you check again and also check if there is an
> entry under HKLM or HKCU  Software\Microsoft\Windows\CurrentVersion\Uninstall?

Nothing in uninstall for *mine*. In HKCU there's no uninstall folder, and under HKLM I find beta 4, and 3.0.0.10, but no minefield.

This was a on fresh user account on vista that I refused all elevation requests for on install.

	Robert Strong (they/them - no direct email) Assignee
	Comment 49 • 15 years ago

I just tried again with a standard user account which I refused elevation for with no HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall registry and it added it.

You say refused all elevation requests... the installer should only request one time. Did it only request one time for you?

	Jim Mathies [:jimm]
	Comment 50 • 15 years ago

(In reply to comment #49)
> I just tried again with a standard user account which I refused elevation for
> with no HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall registry and
> it added it.

It didn't add it here. Of course I have two other versions of Fx installed as well. Not sure if that would effect it. The account is a standard user account, no other changes. 

> 
> You say refused all elevation requests... the installer should only request one
> time. Did it only request one time for you?

Once on the initial install right before the first dialog. I unchecked set as default in the install, and once when the browser opened, I tried to set it as default, and it elevated again. I cancelled both of those. The default setting from there worked fine.

Anything you want me to send you from the install folder / reg / account?

	Robert Strong (they/them - no direct email) Assignee
	Comment 51 • 15 years ago

Could you attach the install.log from the installation directory?

	Robert Strong (they/them - no direct email) Assignee
	Comment 53 • 15 years ago

Is there any chance that you changed permissions in your registry?

It appears that your test account which refused elevation had permission to write to HKLM\Software\Mozilla\ and Software\Microsoft\MediaPlayer\ShimInclusionList\ but not to Software\Microsoft\Windows\CurrentVersion\Uninstall\. On my standard user account I was not able to write to any of those keys.

	Jim Mathies [:jimm]
	Comment 54 • 15 years ago

(In reply to comment #53)
> Is there any chance that you changed permissions in your registry?
> It appears that your test account which refused elevation had permission to
> write to HKLM\Software\Mozilla\ and
> Software\Microsoft\MediaPlayer\ShimInclusionList\ but not to
> Software\Microsoft\Windows\CurrentVersion\Uninstall\. On my standard user
> account I was not able to write to any of those keys.

I've not mucked with registry permissions. But you're right, 

HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla

Has full control permissions for everyone, as does the root Software.

	Robert Strong (they/them - no direct email) Assignee
	Comment 55 • 15 years ago

Ya know, I've ran into a couple of installers previously that when elevated modify the rights to some of the registry and grant full control to everyone (an EXTREMELY bad practice) which I highly suspect is what happened to your system. We definitely don't do that ourselves and it is possible that HKLM\Software had been modified which HKLM\Software\Mozilla inherited. The first time I ran into it I pulled my hair out trying to figure what was going on.

	Jim Mathies [:jimm]
	Comment 56 • 15 years ago

Comment on attachment 378456 [details] [diff] [review]
patch rev1

alright, sorry for the hold up.

	Jim Mathies [:jimm]
	Comment 57 • 15 years ago

(In reply to comment #56)
> (From update of attachment 378456 [details] [diff] [review])
> alright, sorry for the hold upI

f this is common, maybe we should file a bug to handle it better in the future.

	Robert Strong (they/them - no direct email) Assignee
	Comment 58 • 15 years ago

This adds an additional check for write access to Software\Microsoft\Windows\CurrentVersion\uninstall.

	Robert Strong (they/them - no direct email) Assignee
	Comment 60 • 15 years ago

Try build is available
https://build.mozilla.org/tryserver-builds/rstrong@mozilla.com-404541-installer3/install/sea/404541-installer3-win32.installer.exe

	Jim Mathies [:jimm]
	Comment 61 • 15 years ago

Comment on attachment 378682 [details] [diff] [review]
patch rev3

fixed!

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 62 • 15 years ago

Comment on attachment 378682 [details] [diff] [review]
patch rev3

a191=beltzner assuming we get a green cycle on trunk

	Robert Strong (they/them - no direct email) Assignee
	Comment 63 • 15 years ago

Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/c62b9ea0c65c

	Robert Strong (they/them - no direct email) Assignee
	Comment 64 • 15 years ago

Pushed to mozilla-1.9.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/72f42db5836b