Closed Bug 374900 Opened 18 years ago Closed 16 years ago

Update without permissions fails - then gets confused after administrator update

Categories

(Toolkit :: Application Update, defect, P4)

Product:
Toolkit
Component:
Application Update
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 383518

People

(Reporter: tadwhitenight, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2 Same philosophy as bug 374800 and 303595, but this post is specific about the annoying repetitive error and repetitive downloads this causes, which is not mentioned in those bugreports. The update fails & gets confused (tries updating even after it's up to date) for non-admin users. Theoretically a full 2.0.0.3 (~7MB) could be downloaded for every non-admin user on a system. I pity the poor update infrastructure. Reproducible: Always Steps to Reproduce: 0. On a Windows XP system with Firefox 2.0.0.2 installed 1. Login as a restricted (non-admin) user and run Firefox. 2. Help -> Check for Updates 3. Download and attempt install, which naturally fails. 4. Login as an administrator and check for updates in Firefox. 5. Download (2nd time!) and install. 6. Login as same user as in step 1 and start Firefox. 7. Updates are auto downloaded (3rd time - now it's the whole 7MB!!!) and again fails. Actual Results: "One or more files could not be updated. ..." error displays every time Firefox is started for this non-admin user (very annoying), until folder "Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox" is manually purged. Expected Results: At a minimum the update should abort after realizing that its already been installed. But why is Firefox as a restricted user even downloading at all? Seems like asking for a devious user to implant malicious code in an update. I could see if something like bug 303595 comment #8 (an update service) was implemented, but this would be more work, windows specific, and prone to its own bugs. Restricted users downloading updates seems like unnecessary headache all the way around, and was disabled in Firefox 2.0.0.0 and 2.0.0.1 so why now?
Confirmed. In a clean XP vm I created an admin user, and a regular user with limited access. Then I installed FF2001 as admin user, and switched to the limited user. The limited user has no option to "Check for Updates" as it is grayed out. Then installed a clean version of FF2002 as admin user, and switched to limited user. Now the user is able to Check for Updates, and I am able to observe the behavior in comment #0 Starting in 2.0.0.2 the updates files are stored in a different place (for Vista compatibility?): C:\Documents and Settings\joe-user\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox Removin the updates directory and xml files will stop the pesky update notification for the limited user.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → 2.0 Branch
This happens with trunk nightlies too.
Note, that because Fx can be installed to a non-admin updateable location (on any OS not just Windows), the proper test for update-admin-ness is write access to the actual program folder, not any admin status in the OS. A good algorithm without another update-program-xx bloat daemon/service is: 1. Always check for updates, even if not an update-admin 2. Save downloaded updates in a folder shared by all users (Somewhere in the "All Users" profile on Windows, somewhere in /var/cache on Unix). This avoids double downloads. 3. If updating Fx or a plug-in requires more permissions, prompt the user to run the updating (but not any re-display of the browser) under an appropriate su/sudo account. On Unix, this involves running xsu, gsu, sudo or su with appropriate options and letting that program prompt the user. On Vista, this involves triggering the "elevated" prompt for that process (can be done with a manifest in the executable). On Windows 2000/XP/2003 this involves the system call CreateProcessWithLoginW and a username/password prompt. On Windows 95/98/Me everybody is an admin. On Windows NT 3.x/4.0 you will need to tell the user to log off and log on as an admin, unless the su implementation from the NT resource kit happens to be installed. Ditto on any UNIX installation without an available su/sudo program installed.
I'm very sorry, but may it be that this is the same thing as https://bugzilla.mozilla.org/show_bug.cgi?id=370280 but just a month later?
No, this is not the same as bug 370280, although related. The main issues in this bug are: 1. The (impossible) update is retried AFTER the program has been updated some other way (e.g. by another user), making it a non-update! At a minimum, the update logic should realize that the program is now at least as recent as the update itself and no longer needs the update. 2. The (impossible) update is retried on EACH browser restart until manually removed in a back-handed non-end-user way.
(In reply to comment #8) > No, this is not the same as bug 370280, although related. > > The main issues in this bug are: > > 1. The (impossible) update is retried AFTER the program has been updated some > other way (e.g. by another user), making it a non-update! At a minimum, the > update logic should realize that the program is now at least as recent as the > update itself and no longer needs the update. Thank you, I've got the point. This bug must have been introduced equally by checkins in Bug 351949. Last good build: 20070205, the first bad one: 20070206.
Depends on: 378598
Why does this depend on 378598? This bug applies to all Windows OS, not just Windows Vista.
Agreed - removed dependency. Manifests relate to the overall update vs. restricted permission situation, but in no way would fix this bug in the update logic.
No longer depends on: 378598
All, First thank you ALL for working on all the bugs and making Mozilla SW great! I'm new to bugzilla and was going to file a bug, but upon following instructions I found this related bug. I want to report a related issue, hence this reply instead of a new bug report. I too use Win XP with Limited user Accounts, and experience this issue of failing updates. I tried updating FF using the right click "Run as.." and select my Admin login, but fails to update the limited account. In my quest to resolve it, searching Mozilla's site I found the feature of Firefox Profile Manager, and created a shortcut to target the default account, but it still fails open the limited account I want to update. So, the related issue I want to bring up is, Should "Run as.." be able to open the FF profile that you target when using Profile Manager or the shortcut? Note, I would love to see Jakob Bohm comment#5 implemented to resolve this update issue. Thank you for your attention to this issue. I'm very sorry for the long comment. I just wanted to save you the trouble of getting a new bug and then re-classifying it as a duplicate. Neon Leon
Flags: blocking-firefox3?
Assignee: nobody → sspitzer
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: --- → Firefox 3 M9
I encountered this bug on the computer of my parents updating Firefox 2.0.0.5 to 2.0.0.6. (In reply to comment #5) > Note, that because Fx can be installed to a non-admin updateable location (on > any OS not just Windows), the proper test for update-admin-ness is write access to the actual program folder, not any admin status in the OS. > > A good algorithm without another update-program-xx bloat daemon/service is: > > 1. Always check for updates, even if not an update-admin Firefox should check the persmissions to update the program folder (and each extension file) before searching for updates and downloading them. This would prevent confusion and traffic. Firefox should display a helpfull message like "You are not authorized to update this software, please contact your system administrator." if the user checked for updates and there is at least one available. > 2. Save downloaded updates in a folder shared by all users (Somewhere in the > "All Users" profile on Windows, somewhere in /var/cache on Unix). This avoids > double downloads. In case of a security issue in the update implementation this would open the door for evil users to place manipulated update files and wait for a priviledged user to run Firefox. > 3. If updating Fx or a plug-in requires more permissions, prompt the user to > run the updating (but not any re-display of the browser) under an appropriate > su/sudo account. [..] This should be done before checking for updates if the user is not authorized to update Firefox or any of the extensions. Just my 2 ¢. :-)
re: 2. Save downloaded updates in a folder shared by all users (Somewhere If you mean having the update routine read from a file location which is writeable to non-admin users, that sounds like a bad backdoor security hole? (You're trusting everyone, which kind of defeats the entire idea of having admin and non-admin accounts, I think.)
(In reply to comment #19) > re: 2. Save downloaded updates in a folder shared by all users (Somewhere > > If you mean having the update routine read from a file location which is > writeable to non-admin users, that sounds like a bad backdoor security hole? > (You're trusting everyone, which kind of defeats the entire idea of having > admin and non-admin accounts, I think.) > The dangers are the same as the dangers caused by someone modifying the update download while traveling over the unsecured Internet. By having the apply-update program redo any signature and other security checks on the files as they are loaded from the insecure on-disk location, any malicious modification would be limited to preventing the update from being applied. At the same time there are some great security benefits: The browser is never run as admin/root, no connection is made to the Internet by admin/root and users are notified about updates even if they never browse as admin/root.
Not quite the same... It's much easier to just put a "bad" software in the "All users" area than modifying a file while being downloaded by the admin. I think we should find the balance between: - private users: should work as unpriviledged users but should keep the software uptodate without big problems. - corporate users: the admin (or a admin-driven update software) should keep the software uptodate. the users should not be bothered with anything (maybe a small "there-is-an-update indicator"). And if this cannot be made with the same configuration then IMHO there should be a way to select this while installing firefox (and tb...) so that also an admin for small business networks is able to handle it in a simple but safe way.
(In reply to comment #20) > (In reply to comment #19) > > re: 2. Save downloaded updates in a folder shared by all users (Somewhere > > > > If you mean having the update routine read from a file location which is > > writeable to non-admin users, that sounds like a bad backdoor security hole? > The dangers are the same as the dangers caused by someone modifying the update > download while traveling over the unsecured Internet. No, it's more difficult to get unauthorized access to the update website or the internet infrastructure w/o anyone noticing and with the browser accepting the modified update as genuine than to have an unpriviledged user account and copy an exploit to some folder. > By having the apply-update program redo any signature and other security checks on the files as they are loaded from the insecure on-disk location, any malicious modification would be limited to preventing the update from being applied. In theory, yes. But if any user can copy any file to a shared location and firefox checks the files in this location every time it starts you just would have to find a security hole in the file handling or signature verification routines to get your exploit loaded. > At the same time there are some great security benefits: The browser is never run as admin/root, no connection is made to the Internet by admin/root and users are notified about updates even if they never browse as admin/root. No, that's wrong. To install the update someone still has to start firefox with a user account which is authorized to manipulate the program folder. This account will most likely be authorized to manipulate system files and other programs as well. Users browsing as root wouldnt even encounter the bug discussed here, because they are authorized to update their browsers files.
(In reply to comment #21) > I think we should find the balance between: > - private users: should work as unpriviledged users but should keep the > software uptodate without big problems. > - corporate users: the admin (or a admin-driven update software) should keep > the software uptodate. the users should not be bothered with anything (maybe a > small "there-is-an-update indicator"). IMHO this choice is already implicitly provided if <any user> decides to install Firefox as a privileged user and to run it w/o the necessary privileges. So the update routine of Firefox (and Tb) should just check if the current user is authorized to update the software. If he is not, Firefox (or Tb) should just do nothing (except for a hint like "There is an update available, but you are not authorized to ..") and wait for an authorized user to start Firefox. Escpecially Firefox (or Tb) should not download and save any updates anywhere w/o the authorization to apply them. If there are services like 'sudo' or 'runas' available, Firefox should try to use them, but this would be nice to have and not mandatory. The unprivileged user would know who to contact or could ignore the hint, any privileged user would be able to install the update. And this would not open a 'backdoor' to slip exploits in easily.
I also would argue that deliberately programming a backdoor in that allowed escalation of privilege in any way (even if it required winning a race contest), or that even might allow escalation of privilege, is a really bad idea. I'd argue that good programming would be to avoid risking such a backdoor, rather than deliberately embracing it in any way.
(In reply to comment #21) > Not quite the same... > It's much easier to just put a "bad" software in the "All users" area than > modifying a file while being downloaded by the admin. > > I think we should find the balance between: > - private users: should work as unpriviledged users but should keep the > software uptodate without big problems. > - corporate users: the admin (or a admin-driven update software) should keep > the software uptodate. the users should not be bothered with anything (maybe > a > small "there-is-an-update indicator"). > > And if this cannot be made with the same configuration then IMHO there should > be a way to select this while installing firefox (and tb...) so that also an > admin for small business networks is able to handle it in a simple but safe > way. > Let me clarify: 1. I am not suggesting that http-spoofing and local file writing are equally easy attacks, just that both attacks have been demonstrated in the past and thus cannot be ignored as "almost impossible". I then proceed to argue that whatever bad would come as a result of either attack would be the same and that a single set of safeguards (such as digital signatures) could protect against both attacks. 2. I am NOT trying to create a back door as comment #24 suggests. Files from a world-writable directory should be treated with the same suspicion as files from a random download URL such as http://mirror.isp.example.com/firefox/latestupdate/ . 3. I am proposing a mechanism such that the only thing run as admin/root would be a non-surfing updater process (the current updater.exe, slightly modified). This implies that a process with less privileges would do the network-visible download. The normal web-surfing / mail-surfing non-privileged browser/mail program fits that role nicely. 4. Just in case someone starts Fx/Tb as admin/root, the update-before-run mechanism would run the update before surfing or reading mail as root, but doing so would no longer be the only way to get and install updates. 5. To protect against a non-privileged user putting a valid update in the shared directory and then waiting for a non-consenting admin to do #4, display the update now/later prompt before running updater.exe automatically on Fx/Tb start (but not when someone directly starts updater.exe, perhaps via a corporate-wide script). P.S. A bulletproof verification of digital signatures implies that the signature verification and the subsequent trusted use are done on one and the same in-memory copy, not on two "consequtive" file reads. Remember the disk is an I/O device and you should never trust input.
[..] > P.S. A bulletproof verification of digital signatures implies that the > signature verification and the subsequent trusted use are done on one and the > same in-memory copy, not on two "consequtive" file reads. Remember the disk is > an I/O device and you should never trust input. Ok, to the point: I am not implying in any way that Firefox or Thunderbird or any opearting system or.. is absolutely bullet proof and secure and.. And that's exactly my point: IF there is a security hole in part of the routines opening the update files and checking the signature, it would be _much_ _easier_ for non privileged users to feed firefox an exploit because _all_ users are able to place files in a public writeable folder. So you would make it easier to exploit Firefox and Thunderbird by reading files from a public writeable folder _at_ _startup_. Asking the user whether to open the file does not improve security unless you could provide a way to verify the file w/o opening it first.. So in my opinion Firefox and Thunderbird should not save updates in a public writeable folder.
Linus, I think the slogan "defense in depth" is often used for the philosophical approach you are espousing here -- looking for graceful survival if imperfections are discovered (horror) in any particular point of any of the perimeters (outer or inner).
Hey Perry. That sounds about right. :-) I just think, Firefox or Thunderbird should not be made 'less secure' just so all users can download an update w/o being authorized to install them.
I often find my dad's pc with a old firefox (and thunderbird) version. he's running with an unpriviledge account on xp home. he doesn't know and doesn't care at all about security update. solution must be able to keep a firefox updated without user intervention. (of course, there should be a flag do disable this.) I think there should be some process with admin rights able to manage update. at boot it should upgrade firefox if an update is available. the update could be downloaded at boot time or by one user in the background like now, which would write it to a public directory. My understanding is that updates are signed so firefox updater is able to know if the update is corrupted. (and can copy it to a directory owned by admin beofre checking to avoid working in a public directory) the admin firefox updater could write a file in a known location to advertise to other firefox process that an update is being done (if the boot is too fast, there's the possibility that the update is not finished when the user logs on and start firefox) this should also work for extension available for all users for extension installed by the user, user is able to update them so they can be updated at boot time.
If the boot is too fast, why not do the it during shutdown procedure ? So do MS XP but I am not aware of the details of the conditions to perform that kind of updates.
> I think there should be some process with admin rights able to manage update. at boot it should upgrade firefox if an update is available. > the update could be downloaded at boot time or by one user in the background like now, which would write it to a public directory. I don't really care if it wants to do an update in the background, but doing this at startup time is definitely *not* cool. Making a user's computer take twice as long to boot is extremely inconsiderate. > If the boot is too fast, why not do the it during shutdown procedure ? So do MS XP but I am not aware of the details of the conditions to perform that kind of updates. I don't think shutdown time is appropriate, either. I'm not sure that it would even be possible to do an XP-style shutdown-update. Even if it is, it's not really desirable. Same situation as startup, it's just rude to the user. A low-priority background thread is one thing, delaying important behavior (startup/shutdown) is another thing entirely. Don't make the user angry.
Keeping software up to date on private Windows computers is a problem _every_ installed third party (read: non-Microsoft) software has. There is AFAIK no software (update) management besides the Microsoft Update, so it is very difficult to implement automatic updates for every developer. This should be done as one service to be used by every installed third party software component instead of one server per installed third party software. Just my 2 ¢.
Target Milestone: Firefox 3 M9 → Firefox 3 M10
As the one introducing the general updating discussions into this bug report, let me just try to clarify things: There are two issues under discussion here: 1. A concrete BUG in how the existing updater.exe responds if *for any reason* the pending update it wants to try has already been applied in some other way, perhaps by another user or another mechanism. This affects EVERY non-admin Fx2 user and needs to be fixed ASAP. 2. A general, *long term* discussion about how to best handle updating Fx and Tb in scenarious where most people are smart enough to never surf or read e-mail under root/admin accounts. This really needs to be split off into its own bug # or other discussion forum. My philosophy regarding the larger issue #2 is this: There are 4 classes of Fx/Tb users: A) Stupid admins who run Fx/Tb as root. This has been a security no-no for ages but happens to be the only scenario that works in the currect Fx/Tb release. This also happens to be the default OS configuration in Windows XP and Windows 95/98/Me. B) Clever admins who run Fx/Tb under a less privileged account to limit the potential damage caused by web and e-mail worms and exploits. This is the default configuratin in Unix, Windows NT, Windows 2000/2003 and Windows Vista. These people need to get the update notification during their normal non-admin surfing, the option to download the update files while still running as non-admin (to limit the risk of someone exploiting the security holes being fixed during the update downloading), and an easy ability to apply the updates under their admin account without a dangerous browser/e-mail window being run in that high-risk environment. C) Semi-trusted users who can ask the admin to authorize the update of their Fx/Tb, even though the admin does not hirself track new Fx/Tb update release events. D) Locked-down users who cannot update Fx/Tb themselves and cannot call tech support.
I just recently received an update notification while logged in as a regular (untrusted) user. Of course I know better than to push the Update button, because I remember that that not only fails, but leads to repeating failure until I track down the profile and delete a bunch of files. I deduce from this experience that 2.0.0.6 is still buggy in some way -- I guess this is case Jakob's case D.
To Perry: If you have access to the admin account, just not at that very moment, this is my case B. If you never have access to the admin account but know how to get someone who does to complete the task for you, it is my case C. If you have no access to the admin account and no access to a person who does, then it is my case D. Neither case works in 2.0.0.6 . In fact the repeated failures will occur even though you said no to the update!
Jakob, thank you for clarifying the cases -- as you seem to have guessed, I was misdiagnosing my case. My case is case B (not case D at all) -- I can indeed obtain access to the admin account, but not at that particular time.
I believe this is a duplicate of 390433 which is already assigned.
(In reply to comment #38) > I believe this is a duplicate of 390433 which is already assigned. I don't think so. Bug 390433 appears to be about coping with UAC, which is specific to Windows Vista. This bug applies to all operating systems.
Same with 2.0.0.7 (I suggest people use their votes... maybe it helps ;-) )
This bug report is mistitled, because it's broader than "Update without permissions fails - then gets confused after administrator update". It's simply "Update without permissions fails and yet keeps trying". Another bug is "Software update gets confused after successful administrator update when failed user updates are pending." I believe this is why there are so many duplicate bug reports.
Here are my suggestions posted in 399603. (Thanks, Jo!) Many unsophisticated users will not know what is going on. They will keep dismissing the notifications about their failure to properly install the next version, and this is tiresome. Even a sophisticated user, who has no administrative privileges on the machine, will be annoyed by this behavior, although they will know to turn off the update checks. I consider there to be three good ways of dealing with this problem. 1. Have the updater check for the required permissions before attempting to update. It can notify the user once if it is unable to update, and give them the option to turn off (which should be default) future automatic updates, leaving it to the administrator to perform them. 2. Install an update NT service like Windows Update. This service can run with the correct permissions to perform an update, and can notify the user agent that an update is complete and a browser restart is recommended. 3. Install new files in the User's Application Data directory (checking for permission, of course!) and use those files until the administrator catches up with the updates on the root copy. Then, the unneeded files can be deleted. In the common case, this would be fine, except it could lead to big trouble on terminal services machines. Also, "roaming profiles" might need to keep several versions around if the machines they roam to do not have identical versions. In all, I think this is a bad default, but could be a good option for power users.
Concerning qualms people have about downloading files by the user agent and then having a "back door" install them, this could be resolved by having the back door download the files, or, if it is preferred that the user downloads them, having the back door download an SHA digest to certify the files. Remember that Windows is designed for the unsophisticated user supported by the underpaid administrator. It is unlikely in many installations that the administrator is choosing appropriate default settings, let alone keeping on top of updates. Perhaps the best solution is a matter of market research, but I am fully convinced that the current solution (annoy the user) is lousy.
(In reply to comment #43) > 3. Install new files in the User's Application Data directory (checking for > permission, of course!) and use those files until the administrator catches up > with the updates on the root copy. Then, the unneeded files can be deleted. > In the common case, this would be fine, except it could lead to big trouble on > terminal services machines. Also, "roaming profiles" might need to keep > several versions around if the machines they roam to do not have identical > versions. Might help if the "Local Settings" folder is used instead of the "global".
According to > 1. Have the updater check for the required permissions before attempting to > update. It can notify the user once if it is unable to update, and give them > the option to turn off (which should be default) future automatic updates, > leaving it to the administrator to perform them. I'd suggest: - Check for updates. - If any found, check if the user has admin permissions. - If admin, install update - If unprivileged user, display message "Update available, ask you admin, or log in as admin" > 2. Install an update NT service like Windows Update. This service can run with > the correct permissions to perform an update, and can notify the user agent > that an update is complete and a browser restart is recommended. Better way, just like virus scanners for instance do it.
FIRST AND MOST URGENTLY: Fix updater.exe, so attempts to apply an already applied update succeed even if the current user has no permission to overwrite whatever files and data would have been overwritten if the update had not already been applied. This is the primary bug here, and very directly affects EVERY FireFox user on Windows EVERY time a firefox update is released! (Sorry for shouting, but there is a lot of noise in this bug log) All the other changes are just icing on the cake and can be done later.
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Priority: -- → P4
This problem is affecting the usability of Firefox and Thunderbird, so I think the priority needs to be higher on resolving this issue. It causes a lot of pain for the users who see error messages and failed patch installs *every* single time they open Firefox or Thunderbird. It creates more work for the IT staff who have to go to every affected machine and install the patches manually. Firefox 1.5 did not install the update if adequate permissions were not there, so in this manner Firefox 2.0 is inferior. When your average user opens Firefox and sees an ever-present error message, I think many will go back to using an error-free Internet Explorer. If nothing else, just handle this problem the same way Firefox 1.5 did. If the user has inadequate permissions to do the install, the install does not occur.
Ditto. I really don't know what gives with this issue. I read the over the code months ago; and, if my memory serves me correct, the code does read to affirm whether a user has administrative privileges. I thought a correction was added several minor revisions ago, but the problem re-occurs. The only thing I can say is that it works like a charm in Vista. Currently, as a consultant, I would be very reluctant to recommend Firefox for XP users simply because it is a royal pain in the neck to administer in a secure environment. This is a very unfortunate situation because it is a great browser, I have used it for years and would recommend it without hesitation. But administrative support of systems is a cost factor to my clients, and having to baby-up to each workstation or handle dozens of support calls after each upgrade makes it counter-productive to use.
Judging from what I read above on the site header, the code revision is targeted for Firefox 3. It is a very low priority (4, out of 5). I would suggest it be raised to at most level 2 and resolved sooner, rather than later. I don't know when Firefox 3 is scheduled for release, but this issue needed to be resolved months ago.
Thanks to Jakob Bohm for defining the issues so well. I am in the 2B camp. I am an admin for three depts in a university and I have been pushing Fx for years, but this issue has brought me to the Rubicon. I am very frustrated trying to keep Fx updated and am faced with a plethora of BAD choices because of this problem. My users are unprivileged, and we are all annoyed at the issues of Fx error messages, and I BTW, cannot always get to their machines to update immediately -- meaning I have had users run in an unpatched state -- yet another security risk that I have not seen mentioned here. Since I can run an auto-patching IE service without having to promote my users, this is looking like a (cough) MORE secure option with me. I find it hard to believe that Fx has placed this bug on the back burner, so to speak.
Wayne, I think the problem of updating Firefox remotely/automatically is probably outside the scope of this bug, so you may wish to file a new one. For the here and now: it isn't particularly difficult to update Firefox in a startup script. Passing the installer -ms will cause it to install silently. (The only slightly tricky thing about using a startup script is determining whether the update is needed or not.) You can prevent users from being bothered by automatically downloaded updates by putting a file in defaults\pref containing this line: pref("app.update.enabled", false); the filename has to sort alphabetically before the other files; I prefer to use an underscore, e.g., _localsettings.js. Of course it is then up to you to keep track of new versions and install them as needed.
Actually this seems to have been resolved in 2.0.0.10 (or perhaps earlier?). The update options are grayed out for non-administrative users. Can anyone still reproduce this problem?
You mean non-admin users _again_ can not check if an update is available ?
Um - yeah, on Windows XP anyway. I /think/ this change came from bug 383518, but I'm getting a bit confused so don't take my word for that. I guess that's not the ideal behaviour, come to think of it. It's good that it doesn't download, but not so good that it doesn't report. You can't even check manually using the Help menu item. I guess this should be reported as a new bug. On the other hand, I'm not sure what's happening on the trunk, this may have already been resolved.
Here are two ideas about this new problem of non-admin users apparently not even being able to check whether there are updates. For now, these users can go to www.mozilla.com and compare the version listed under "Download Firefox" on that page to the version listed on their Help menu, true? A nicer answer would be a prominently-linked "Check for Updates" page on mozilla.com that anyone could visit. The mozilla.com server could check the browser being used and tell the visitor whether they're up-to-date. If an update is needed, the results page could tell the user steps to follow to decide whether they have permission to update themselves -- or if they have to ask an administrator, or switch themselves to an admin account. This could help users who aren't "techie" enough to understand everything they need to know/do. And, if it's "too hard" to automate all of this from within the browser code, this might be an acceptable compromise. (I don't know much about the code, how users update Firefox, or the mozilla.com server... so I'd appreciate no flaming replies. I'm just an individual user tracking this bug, and I wanted to mention these ideas in case they're useful.)
How about a dialog window that shows up and notifies the user that there is an update available (Contact your sysadmin etc.). With an OK button, and a "Don't show me this message again for this update" check box? Not sure on the "for this update" part. On one hand there might be people who never want to see that message, because they never have to worry about this. On the other hand there are people who have to worry about this who might accidentally turn this dialog off. Maybe a good compromise could be to make it possible for the sysadmin to turn this dialog box off permanently, and the user can only turn it off for the *current* update (new updates will turn the dialog back on)
If people never want to see when updates are available they can turn automatic checking for updates off in their preferences. However, this discussion should probably be taking place on a different bug report.
Version: 2.0 Branch → Trunk
Harry, thanks for the pointer on the pref.js file deactivating auto-update. I haven't had any issues lately (currently on 2.0.0.11). BUT -- automatic installation is not what the enterprise administrators are concerned about. What is of concern is that update processes of any software must follow specific protocols based on the security structure of the O/S. The update procedure, quite frankly, of Firefox had been a train wreck. The people who most typically encounter this most dramatically are the ones who must answer several hundred phone calls from confused users.
I think my problem somehow close to the listed. I am the only user of Fx on my PC, so I always get the notice of the same available update. Recently I got an update for my 2008010104 (current) version. The new one is 2008010405. 1. The first time I start minefield the update is available for download. 2. I download the update, push "Restart" and nothing happens. Fx is closed but with no restart. 3. I start Fx manually, but nothing is updated. If i push manual search for updates, 2008010405 is being found again, but download never starts: it is in "Connecting to the update server..." state. 4. I stop it and "Check for updates" again. Now its state is stalled again but shows "8.4Mb of 8.4Mb at X.X Mb/sec; 00:00 remain". 5. I close Fx and start it again. Now I'm back with p.1 Is there any way I can manually install the update or skip it?
Not going to continue to block on this. If you disagree with this decision, please renominate with reasons why we can't ship with this in final
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
I don't understand what the fuss is. Note that Admin status is not necessarily required for update, even on XP Pro. The correct logic seems simple: Always check for updates; If user has the required Write access, then download and install update Else notify user/request password/sudo etc.; //see comment 5 for details Notification doesn't have to be debilitating or annoying, but it does have to be unmistakable and unforgettable. This avoids all the problems I know about: unnecessary downloads, confusion, extra load on servers. Upgrading the severity to Major. Is there anything wrong with the logic? Would filing a new bug report with this logic help to get some action on this?
Assignee: moco → nobody
Severity: normal → major
Sorry, missed with mouse and accidentally reassigned bug, but I'm not sure it makes any difference. Feel free to correct this.
Assignee: nobody → moco
Assignee: moco → nobody
I have this problem; what exactly do I need to remove? I don't want to hamstring my fox. Thanks, M (In reply to comment #1) > Confirmed. In a clean XP vm I created an admin user, and a regular user with > limited access. Then I installed FF2001 as admin user, and switched to the > limited user. The limited user has no option to "Check for Updates" as it is > grayed out. > > Then installed a clean version of FF2002 as admin user, and switched to limited > user. Now the user is able to Check for Updates, and I am able to observe the > behavior in comment #0 > > Starting in 2.0.0.2 the updates files are stored in a different place (for > Vista compatibility?): > > C:\Documents and Settings\joe-user\Local Settings\Application > Data\Mozilla\Firefox\Mozilla Firefox > > Removin the updates directory and xml files will stop the pesky update > notification for the limited user. > (In reply to comment #1) > Confirmed. In a clean XP vm I created an admin user, and a regular user with > limited access. Then I installed FF2001 as admin user, and switched to the > limited user. The limited user has no option to "Check for Updates" as it is > grayed out. > > Then installed a clean version of FF2002 as admin user, and switched to limited > user. Now the user is able to Check for Updates, and I am able to observe the > behavior in comment #0 > > Starting in 2.0.0.2 the updates files are stored in a different place (for > Vista compatibility?): > > C:\Documents and Settings\joe-user\Local Settings\Application > Data\Mozilla\Firefox\Mozilla Firefox > > Removin the updates directory and xml files will stop the pesky update > notification for the limited user. >
(In reply to comment #65) Sorry, the support forum is here: http://forums.mozillazine.org/viewforum.php?f=38 or here: support.mozilla.com .
IMHO it probably would be easier on the user to prompt for elevation with UAC before installing add ons, instead of making the user elevate themselves before running Firefox. Even if the install updates option was grayed out, it would still annoy users who think they're running as administrators, yet have not responded to the UAC dialog by running Firefox as an admin.
Target Milestone: Firefox 3 beta3 → ---
(In reply to comment #67) > IMHO it probably would be easier on the user to prompt for elevation with UAC > before installing add ons, instead of making the user elevate themselves before > running Firefox. Even if the install updates option was grayed out, it would > still annoy users who think they're running as administrators, yet have not > responded to the UAC dialog by running Firefox as an admin. > Agreed, comment #5 contains my proposed secure algorithm for doing this right.
Product: Firefox → Toolkit
(In reply to comment #0) > > Steps to Reproduce: > 0. On a Windows XP system with Firefox 2.0.0.2 installed > 1. Login as a restricted (non-admin) user and run Firefox. > 2. Help -> Check for Updates After bug 383518 landed it is no longer possible to check for updates as a user that doesn't have write access to the install directory. > Expected Results: > At a minimum the update should abort after realizing that its already been > installed. But why is Firefox as a restricted user even downloading at all? > Seems like asking for a devious user to implant malicious code in an update. I > could see if something like bug 303595 comment #8 (an update service) was > implemented, but this would be more work, windows specific, and prone to its > own bugs. Restricted users downloading updates seems like unnecessary headache > all the way around, and was disabled in Firefox 2.0.0.0 and 2.0.0.1 so why now? No longer possible due to bug 383518 landing so marking dupe of bug 383518
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.