Closed Bug 303595 Opened 15 years ago Closed 13 years ago

updates under windows as non-administrator user not possible

Categories

(Toolkit :: Application Update, enhancement)

x86
Windows XP
enhancement
Not set

Tracking

()

RESOLVED DUPLICATE of bug 383518
Future

People

(Reporter: jdd, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

When running as an unprivileged user (i.e. user without administrator rights)
under Windows XP, firefox 1.05 and earlier (and possibly later; there are no
updates for 1.06 yet so no way to check) will successfully download the update
after clicking on the critical updates button, but then will report that the
user lacks administrator privileges and offer a dialog asking whether or not to
continue the installation without privileges (and recommending aborting the
installation).  Rather than offer to continue without privileges, what firefox
should offer is the choice to abort or to continue the install using a specified
administrator account and password (the so-called "run as" option in Windows). A
less satisfactory workaround would be to offer the option to leave the
downloaded installer .EXE so that the user could then at least manually execute
it using "run as".

Reproducible: Always

Steps to Reproduce:
1.Click on critical updates when running as non-priviledged user
2.Observe dialog.



Expected Results:  
Dialog should offer option to abort or to continue as a priviledged user.  A
less satisfactory option would be to offer the option to abort or to leave the
.EXE behind (e.g. on desktop) so that the user can manually run it as a
priviledged user via "run as".
Component: OS Integration → Software Update
QA Contact: os.integration → software.update
I don't think we have any plans to improve this for Firefox 1.5, but it is a
valid bug.  Moving to the future bucket.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
Another quick fix would be to warn the user before even downloading the update.
Then at least you could log in as administrator without wasting time downloading
it twice. But I agree downloading as nonadministrator and offering to use "run
as" would be more convenient. But wouldn't it be more secure to log in as
administrator when needing to update?
bz@til asks:

>But wouldn't it be more secure to log in as
>administrator when needing to update?

It's actually less secure to run the whole browser as
administrator, which is what you would need to do to use firefox
update.  You could, I suppose, download the update manually
as an unprivileged user and then execute it as an administrator using
"run as" (this is the workaround I used), but that's a cumbersome
process that the firefox update function is supposed to make it
possible to avoid.
This also applies to automatic updates from, eg, FF 1.5.0.1 to FF 1.5.0.2.

Obviously the update cannot be applied, but "Check for Updates" should be available, not greyed out, and the automatic check should also check whether an upgrade is available. Then if an update is available, the user should be told that an upgrade exists but an administrator is needed to install it.
This bug also occurs when logged in as an Administrator that implements the security precaution of running Firefox 1.5.0.3 and ealier with DropMyRights and SetSafer from Microsoft.  This has the effect that Check for Updates... is grayed out.

It appears that the mechanism for graying out the Check for Updates... field in the Help pull-down selection menu may be to simply check to see if the Sid is a deny-only Sid, where it is assumed that Firefox is being run from a limited user account.  However, in this case, Firefox is being run from an Administrator account with limited rights which blocks access to checking for updates that could otherwise be downloaded and applied.
An update from a Windows Limited (nonadministrative) account IS possible if the user has write privilege in the program directory.  For example, mine just updated automatically to 1.5.0.5, on two computers.
Perhaps it is better to split the update, running as administrator, with the main browser, running at the lowest level of privilege reasonable?
My 2 cents:
 - the "Check for Update ..." menu should always be available. It is very cumbersome to get admin privileges, just to check if updates are available.
 - update as non-admin : maybe the new automatic update feature planned for v3 can be used:
   - user clicks "Update"
   - FF tells the update service to perform the update
   - update service performs the update and gives feedback to running FF (to tell the user to restart it or whatever is needed)
Duplicate of this bug: 366414
Duplicate of this bug: 287667
This is similar to a bug I just filed. I was not given a dialog about "lacking Administrative rights" however, at least, not that I recall. 

  https://bugzilla.mozilla.org/show_bug.cgi?id=374800

Someone who understands this issue might be able to figure out whether that should be marked as a duplicate of this.

As far as I can tell (but I might be mistaken, and wouldn't bet money), it downloaded the update, but cannot use it, and when I logoff and logon as a local admin, it cannot find the update it downloaded. 

(I tried to search using the boxes provided when I filed that bug, but it filled these tiny grids with many results that weren't sortable, so I couldn't figure anything to do except try to scan them somewhat, and then give up. I never found this bug at that time.)
Duplicate of this bug: 374800
I'm not sure that is entirely a duplicate.

I reported it because the 2.0.0.3 upgrade seems stupider than the previous ones.

Previous ones want to install as a limited user (which seems stupid), but 2.0.0.3 seems to insist on installing as a limited user, and of course fails, and then tries again next time I logon as a limited user.

The previous ones at least asked, and didn't keep retrying and failing.
Agreed with Perry about 2.0.0.3

In order to make it easier for Firefox to install updates as a limited user, I had originally installed Firefox by temporarily changing the limited user to an
administrator, installing Firefox, then revoking administrative privileges for
that user.  This has, for some previous updates, allowed Firefox to automatically install updates as a limited user. 

However, for 2.0.0.3, when offered the choice of attempting the update now or
waiting until the next time firefox was used, I chose the latter.  Then the
next time firefox was started, the update was attempted, failed, attempted
again, failed, etc. ad infinitum, as Perry describes.

My ad hoc workaround was to switch to an administrative user, then give the limited user running firefox full privileges on the
C:\Program Files\Mozilla Firefox directory, at which point the looping update attempt finally succeeded.

Incidentally, Firefox' inability to update automatically when running as a
limited user is probably the largest barrier to its adoption over IE in my shop.
This workaround of giving the limited user full access to the Firefox installation directory is the best we have been able to come up with so far. 
(In reply to comment #14)
> waiting until the next time firefox was used, I chose the latter.  Then the
> next time firefox was started, the update was attempted, failed, attempted
> again, failed, etc. ad infinitum, as Perry describes.

This is covered by bug 340535.
Are you sure?  Bug 340535 complains about an update looping because files are in use.  This describes an update looping because it doesn't have the right permissions to actually complete.  Seems to me like it's a different bug with similar symptoms.

Yes, I just saw this on another machine -- the 2.0.0.3 upgrade tries to run without asking, and of course fails.

Earlier upgrades were not this stupid; they at least prompted first.

I myself don't expect Firefox to be able to upgrade as a limited user -- I don't want it to, that would be a big security hole (IMHO), if a limited user could overwrite programs in %ProgramFiles%.

I would prefer it at least prompt (as it used to). Actually, I really would prefer that they would separate the update choices for extensions (which obviously are per-user) and the program (which obviously is not per-user). As far as I can tell, these two are conflated with only one set of update choices, so either you don't get extension updates, or you get extension updates but live with failures by the stupid program update.
> Firefox' inability to update automatically when running as a limited user is probably the largest barrier to its adoption over IE in my shop.

Um, but IE also cannot update as a limited user.?
IE doesn't try to update as a limited user.

It seems obvious to me that Firefox should not attempt to update if it finds it's running without administrator privileges.
re: Firefox as limited user

I've not much interest in installing or upgrading Firefox as a limited user, but in these various bugs, I had the impression some people were working with user-local firefox installations, created and perhaps upgraded as limited users.

I don't think IE supports that model at all, and I've not a lot of desire for it on any of my machines now, but I'm willing to believe some people need that functionality...
IE doesn't need to update itself, it relies on Windows Automatic update for that, which can successfully run (and update IE) even if the user using the machine does not have administrative privileges. Firefox obviously cannot rely on Windows update, it needs its own mechanism. But the desired effect is the same as in the case of IE: we need a way to keep the web browser up to date without requiring a user with administrative privileges to log in to the machine periodically.

Ideally, firefox should look to see if the files and directories it needs to be able to modify in order to update itself are modifiable by the user it's running
as; if it is, it should go ahead and update itself.  If it isn't, it should do something reasonable, like offer the choice of entering an admin password to continue with the update, or the option of deferring until an administrator can log in.

And while it's not ideal to have firefox' program directory writeable by a limited user, it's still better than running as an administrator, or using
an unupdated version rife with security holes.

This same issue holds for Thunderbird vs. Outlook.
If you're not pushing updates via GPO, I think you are already logging in routinely as an administrator to update everything else, so I think Firefox should be the same as other apps.

Certainly many of us would prefer to not have random updates behind our back, for several reasons including configuration control.
The current (as of 2.0.0.2 & 2.0.0.3) update methods have flaws on restricted user accounts - see bug 374900.  If FF has write permissions to its directory (generally an admin) then it should download & update - that's fine.

BUT if FF lacks permissions (generally a restricted user) it, downloading in the user account is a definite no no, which is what is currently going on.  Even if an account with sufficient permissions then installs the update, it is no longer secure since the download could have been infected/tampered with in the lower-privileged account.  Cryptographic signatures could help, but they would need to be implemented carefully.

If people really want the ability to download as a user account, then it should be implemented as a "Mozilla Update Service" that receives a simple check command from Firefox (or Tb or other client) in the user account.  The actual download and installation occur in the service's account (I think SYSTEM on Windows machines).  I've noticed several vendors adopting this strategy such as Microsoft, Apple, Logitech, etc.  The code for the service should be as clear and short as possible, since with elevated privileges comes increased responsibility to stability and security.
Note that the last part is just an elaboration of comment #8
BTW, I've opened another bug, because 2.0.0.3 is much worse than described here -- it is repeatedly trying to update as a limited user, even a version which has already been uninstalled and then reinstalled as 2.0.0.3 as an admin. I've seen a second box XP exhibiting this problem now -- login as a regular user, after Firefox 2.0.0.3 has already been upgraded by the admin, and stupid firefox insists on downloading the 2.0.0.3 update again and then trying and of course failing to apply it (as a regular user).
Ditto Perry.

It is interesting this issue has remained open so long.  You can imagine the headache for enterprise network administrators, having several hundred users seeing a bogus "Software Update Failure" message appear each time they use Firefox.  It is bad enough with the four users in this family.

I hope the coders can resolve this soon.  Vista will force this issue but it also may provide the API to automatically present the request for an administrator password.  Does anyone know if this is the case for Firefox 2.0.0.x?
Under Vista with UAC, I was able to perform the update from 2.0.0.2 to 2.0.0.3 correctly as a limited user.
Looks like the riddle was supposedly resolved with the 2.0.0.3 update for Windows XP.  I suppose we will see with the next update.

From the release notes, issues resolved include:
"Software Update will not work if Firefox is installed to a location on your disk to which you do not have write access, since Software Update needs to replace or create files in this location. "
> Looks like the riddle was supposedly resolved with the 2.0.0.3 update for
Windows XP.

Haha. In case you're not being sarcastic, 2.0.0.3 update is much worse about this than the previous ones; 2.0.0.3 is the first one I've seen that insists on trying and failing and dying over and over, and even continuing after the program has been updated.
Ditto -- the problem is still there.  More than likely, it is due to version 2.0.0.3 executing the flawed Update module.  I'm going to check more mundane avenues to see if the problem can be resolved without having to monkey around with countless user accounts.
Duplicate of this bug: 382938
Today  FF informed me, that v2.0.0.4 update is available and that it has downloaded the update. My choices :
 - restart FF now
 - no restart, but the updates will be applied on next restart

Funny thing, I am running v2.0.0.4 since yesterday.

But I guess the magical procedure of "updating a piece of software" is a fundamental computing problem, with a solution expected somewhere in 2040, with an obligatory Nobel prize ...
(In reply to comment #32)
> Today  FF informed me, that v2.0.0.4 update is available and that it has
> downloaded the update. My choices :
>  - restart FF now
>  - no restart, but the updates will be applied on next restart
> 
> Funny thing, I am running v2.0.0.4 since yesterday.
> 
> But I guess the magical procedure of "updating a piece of software" is a
> fundamental computing problem, with a solution expected somewhere in 2040, with
> an obligatory Nobel prize ...
> 

Same mystery.  I activated a file-tracker tool in Avast and noticed that the jam up appears to be in the Updater files clustered under the user's Local Settings\Application Data\Mozilla .... \Updates\0 folder.  There is a log file that tracks what succeeds or fails.  Wish I could attach the log file.

Anyhoo -- The update process is seamless for Admin accounts only.  Tested on two admin accounts.  One user-level account updated without a hitch, but I now have two user-level accounts that have updated to 2.0.0.4, but still persist in showing an error message saying that certain files are in use or the user does not have adequate privileges to update.

All this on my home computer.  Can't imagine what a nightmare it would be to use this tool on an enterprise network.

I sure wish someone at Mozilla could give me a clue as to how to resolve this problem without having to upgrade a user to temporary admin privileges, or reverting to a clean install the of the program.  I like to take part in resolving the update bug.
I got a notice today that this issue also happens for one of our computers at work. All of our users are working with restricted rights and shouldn't be able to update Firefox. Nevertheless all the upgrade files are downloaded to the folder Eric already pointed out. On each start of Firefox the message appears that the upgrade cannot be finished. After removing the files under "Local
Settings\Application Data\Mozilla\Updates" the the message doesn't appear anymore. But as long as normal users are able to download upgrades this issue will return until the upgrade is performed by an administrator or you deactivate the automatic update mechanism within the options.

As a temporary solution we only should download the upgrade files if the current user has write access to the program folder.

Mike, can we easily disable the menu entry under help and the underlaying update function? 
(In reply to comment #34)
> But as long as normal users are able to download upgrades this issue
> will return until the upgrade is performed by an administrator or you
> deactivate the automatic update mechanism within the options.
Some people would argue that this option works... ( Bug 319198 , Bug 372123 ).

So with these bugs combined the only reliable solution for non-admin users (with standard permissions) in companies is to block access to mozilla mirrors for them ? :|

BTW Does anybody compiled or is somewhere available list of mozilla mirrors in txt file which could be imported to e.g. squid in order to allow / deny access to them ? (http://www.mozilla.org/mirrors.html - I know I can use this page but maybe mozilla could put link to txt file which lists them nicely :) ? )
I'm assuming this is a joke? Obviously the update bugs need fixing.
marking this as dupe of bug 383518, since this bug has morphed over a long time (orginal report for Firefox 1.0.x) and the latest comments here describe now Bug 383518.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 383518
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.