383518 - Non-Vista Windows users are prompted for updates they cannot apply

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[Robert Helmer [:rhelmer]]

On Windows XP with 2.0.0.3, a non-administrative user will be prompted to download and apply an update, when they do not have write access to the application directory.

sspitzer looked into it and says that this is probably due to the fact that Firefox downloads to the user's directory ("Documents and Settings\user\...\") instead of to the application directory, and the canUpdate() check passes now:
http://mxr.mozilla.org/mozilla1.8/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1498

This is ok on Vista because we can prompt the user to grant access to the application directory, but not on XP or presumably NT (users will be prompted every day).

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

Possible Dup ?  Lengthy heated discussion here it seems: 
https://bugzilla.mozilla.org/show_bug.cgi?id=303595

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I'm not happy that bug 303595 is duped to that one. It has been describing the same problem for a really long time and many information was collected. It makes me sadden that new bugs are filed without searching for already existing ones. 

Comment 7

[Robert Helmer [:rhelmer]]

(In reply to comment #6)
> I'm not happy that bug 303595 is duped to that one. It has been describing the
> same problem for a really long time and many information was collected. It
> makes me sadden that new bugs are filed without searching for already existing
> ones. 

Hi Henrik, we did find and were discussing bug 303595 but filed a new one at the request of the developers working on it, to make it clear what the current issue is. Sorry for any confusion this has caused.

Comment 8

[Jesse Ruderman]

See also bug 318855, which is more specific about the desired behavior: tell users that their version of Firefox needs to be updated by an administrator, but don't taunt them with an "update" button that doesn't work or harass them every day.

Comment 9

[Przemyslaw Bialik]

Please check out also Bug 374900 - I think it can be marked as a duplicate or dependent on this one.

Comment 12

[(not reading, please use [e-mail] instead)]

Attachment: patch

for windows, non-vista, we need to check if we can create a file in the actual app dir, as that's what updater.exe will do when it attempts to apply the mar.

Comment 13

[Simon Bünzli]

What about checking whether we're on Vista (or above) at startup and either (1) set KEY_UPDROOT to KEY_APPDIR if we're not (will result in some duplicate but harmless no-ops) or (2) apply that check wherever KEY_UPDROOT is needed? E.g.:

> // On Windows version below Vista this will lead to checking the application
> // directory twice instead of trying an always user-writable location first.
> const KEY_UPDROOT
>   = parseFloat(Components.classes["@mozilla.org/system-info;1"]
>                          .getService(Components.interfaces.nsIPropertyBag2)
>                          .getProperty("version")) < 6 ?
>     "UpdRootD" : KEY_APPDIR;

Or:

> const gWindowsVersion
>   = Components.classes["@mozilla.org/system-info;1"]
>               .getService(Components.interfaces.nsIPropertyBag2)
>               .getProperty("version");

and later (where we could of course also locally retrieve the Windows version)

>     try {
>       if (gWindowsVersion >= 6)
>         appDir = fileLocator.get(KEY_UPDROOT, Components.interfaces.nsIFile);
>     } catch (e) {
>     }

Comment 14

[(not reading, please use [e-mail] instead)]

Simon, could you elaborate on why you recommend that?

Note, although we originally did it for vista, using the alternative place (for the update directory) makes sense on windows xp, instead of under c:\program files\

If on XP, we use the app dir, we will have this bug:

1) an admin user gets an update, but doesn't apply it (so it is pending)
2) the admin user logs off
3) a non-admin user logs on
4) if they go to options | advanced | update, they will see the pending update in the update history.  but, they can't apply it.

I just tried this with 1.5.0.12 -> 2.0.0.4, and confirmed it was a bug.  on the trunk (and with 2.0.0.4), this would no longer happen.

Comment 15

[(not reading, please use [e-mail] instead)]

> on the trunk (and with 2.0.0.4), this would no longer happen.

...because the update would not be C:\Program Files\Mozilla Firefox, and visible to the the non-admin user, but because it would be in:

C:\Documents and Settings\AdminUser\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox

Comment 16

[Simon Bünzli]

(In reply to comment #14)
> 4) if they go to options | advanced | update, they will see the pending update
> in the update history.  but, they can't apply it.

What's wrong with showing the current update state even if the user can't do anything about it? At best it would remind him/her to soon apply the update (as it should anyway per bug 318855).

Of course, if you're saying that there's a button which doesn't work when clicked, that button should be disabled depending on .canUpdate .

With your patch, what happens when (1) an admin user gets an update but doesn't apply it; and then (2) a different admin user gets the same update and applies it? Will the first admin user be notified again, will the update remain marked as pending in the update history, or will it be silently deleted?

Comment 17

[Eric Niewoehner]

I am thinking through the update process to see if we can find some improvements in its design.

1)  It is determined that the user should control the update process.
2)  The update of the Firefox program core is conducted by an administrator
3)  The problem, as it currently stands, is the user-level update components

In my case, as a simple family home network, I have five accounts on one computer.  For the 12 year old to be riddled with update windows is a bit ludicrous, as well as my wife (who is challenged simply by using e-mail).  <i>My suggestion -- make the user-component updates seamless.</i>

Second suggestion is to borrow from a page in other applications (such as OpenOffice).  <i>Have the user-update code deposited in a core directory in the Program Files folder rather than depositing stuff in the user's folder. </i> Why the update code needs to be in the user's folder is still a mystery to me.  User folders only need to be invoked if there is a need to create a temporary holding tank for files in transition. Maybe that is the case now.  Let me know if that is so.

I will create a separate message regarding the discussion on the Update button.

Comment 18

[Eric Niewoehner]

Regarding the Update button:

Seems that some of the discussion revolved around the problem of multiple users tinkering with the Update feature in Firefox.  One idea may be to add  a console accessible only to an administrative account.  This field would be activated in the event the user is an administrator where they could designate a user who is authorized to retrieve and manage updates.  This would prevent unnecessary use of the update retrieval in business environments.

This console could also designate the download folder.  In my case, I use a DUMP\MOZILLA folder to store updates.  The DUMP folder is designed for non-administrative access for specific accounts, keeping Internet traffic separate from executable application files.

When users access the Options console, only the authorized user will be able to access the fields that manage update announcements and downloads.  When a download occurs, it will go to a directory that the administrator has determined .  An update icon appears in the upper right corner of the Mozilla browser (a feature I like with OpenOffice).  The authorized user then knows that an update is available, can log on as an administrator, and initiate the update.

As mentioned previously, the typical user does not even need to know that an update has occurred.

Comment 19

[John DiMarco]

Eric wrote:
>2)  The update of the Firefox program core is conducted by an administrator

I claim it should always be possible to install firefox in such a way as to make it completely updateable by a limited user.  We have system configurations (e.g. notebooks) where there are long periods of time in which there is no easy access to an administrator.  While it is perhaps OK to leave many application programs unpatched during such periods, a web browser is an exception.  We are presently configuring such systems so that the limited user who uses the notebook can update firefox (we set the permissions for the firefox install directory accordingly).  I don't want this option to go away.

To those who might think this is unwise: this is a classic security tradeoff: i.e. is it more important to keep the firefox core unwriteable by a limited user (e.g. to defend against malware attacking that core), or is it more important to patch quickly?  The best call depends on the situation (what sort of machine is it and how will it be used?) I urge both options to continue to be available, so that the system administrator can make the appropriate call based on the particular security risks of each individual system.

Comment 20

[Robert Strong (they/them - no direct email)]

Comment on attachment 270978 [details] [diff] [review]
patch

Reviewed and discussed this with Seth... looks good and thanks

Comment 21

[(not reading, please use [e-mail] instead)]

fixed.

I'll respond to Simon, Eric and John's comment #16 - #19 in follow up comments (or bugs).

Checking in nsUpdateService.js.in;
/cvsroot/mozilla/toolkit/mozapps/update/src/nsUpdateService.js.in,v  <--  nsUpda
teService.js.in
new revision: 1.138; previous revision: 1.137
done

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Seth, can we also clear the whiteboard or is it still valid?

Comment 23

[(not reading, please use [e-mail] instead)]

updating whiteboard.  

adding back blocking fx3? (I would not ship fx 3 without this fixed.)

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #23)
> adding back blocking fx3? (I would not ship fx 3 without this fixed.)

This bug is marked as fixed on trunk. Why we need this blocking flag? I'm a bit confused.

Comment 25

[Benjamin Smedberg]

In case the bug were reopened/backed out.

Comment 26

[David Pennington]

Hi, You'll have to forgive me because I'm a BugZilla n00b, but I'm still experiencing issues with something like this when just updating to FireFox 2.0.0.5.

On Windows XP Pro, as a non-privileged user automatic updates are set so I get asked do I want to apply the update.  To which I say 'yes', then the update fails because of lack of admin privs.  Fair enough.  So, as I am also a sys admin I log in as admin and apply the update to 2.0.0.5.  Works great.

However, when I log back in as the unpriv user, somehow FireFox doesn't know that it's now at version 2.0.0.5 as installed by admin and still tries (unsuccessfully) to install the update.

I believe this also happened to me when I upgraded using exactly the same steps to Thunderbird 2.0.0.4 .

I just wanted to make people aware of it as it is a very annoying bug.  I have no problem upgrading programs as administrator, but then actually still trying to apply the same update as unpriv user seems pretty silly.

Regards, David Pennington

Comment 27

[Henrik Skupin [:whimboo][⌚️UTC+1]]

David, this bug will be fixed in Firefox 2.0.0.6.

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, I tested this fix with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071705 Minefield/3.0a7pre and I'm not able to update to the newest nightly build when I have limited rights. The menu entry is disabled. Could someone test it on Windows Vista so this bug could be fully verified?

Comment 29

[Perry]

The mozillazine FAQ states that this bug is fixed in 2.0.0.4. This is quite a false statement?


  http://kb.mozillazine.org/Updates_reported_when_running_newest_version

Comment 30

[Henrik Skupin [:whimboo][⌚️UTC+1]]

See related bug reports on the bottom of the mz page. That are another issues and have nothing to do with this bug. 

Comment 32

[Carsten Book [:Tomcat]]

(In reply to comment #28)
> Ok, I tested this fix with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9a7pre) Gecko/2007071705 Minefield/3.0a7pre and I'm not able to update to
> the newest nightly build when I have limited rights. The menu entry is
> disabled. Could someone test it on Windows Vista so this bug could be fully
> verified?
> 

On Vista its still the "old" behavior. The Update Feature is also active for
non-admin user and on Restart after Update the UAC comes up and asked for the
admin password. I think this is okay for vista, see comment #0 from rob

Comment 33

[(not reading, please use [e-mail] instead)]

Carsten is right:  we still want the "old" behavior (old == before this patch).

for non admin users, they can get the update and then get the UAC dialog.

clearing status whiteboard, based on henrik's comment #28.

will seek approval for 1.8.1.6 (aka fx 2.0.0.6 / tb 2.0.0.6)

Comment 34

[Perry]

This bug appears to not be fixed in 2.0.0.6.

I noticed that this bug is set to VERIFIED FIXED, so I'll open a new one for the bug I'm seeing on 2.0.0.6 right now, but it does look just like this one...

Comment 35

[Christian Hernmarck]

There are already very similar bugs open:
Bug 379400
Update without permissions fails - then gets confused after administrator update

Bug 318855
When Firefox doesn't have write access to itself, "Help/Check for Updates" should not be disabled, but should perform check anyway (and, on Linux, prompt for root password)

IMHO they all deal with the same problem: when the rights of the user are not enouggh to make an update no update should be performed in any way.

Comment 36

[Christian Hernmarck]

Sorry Bug 374900
Update without permissions fails - then gets confused after administrator
update

Comment 37

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #34)
> This bug appears to not be fixed in 2.0.0.6.
> 
> I noticed that this bug is set to VERIFIED FIXED, so I'll open a new one for
> the bug I'm seeing on 2.0.0.6 right now, but it does look just like this one...

There is no need to open another bug on this. The bug is FIXED in the code that will be Firefox 3, which is why the bug is resolved. The patch has the flag approval1.8.1.7 set to ?, which means approval is being requested for it to be included in Firefox 2.0.0.7.

Comment 39

[John DiMarco]

I noticed in 2.0.0.5 at least that if a user without sufficient privileges downloads an update which then is not successfully installed due to lack of required permissions, the update is tried each time that user starts up firefox.
This continues even after the firefox has been updated by another user that
does have the required privileges.  My suggestion is that an already downloaded update be deleted if the user that downloaded it has insufficient privileges to apply it, or if the firefox has already been updated.

Comment 45

[Eric Niewoehner]

One concern that may need to be addressed in this thread is the role Firefox plays in enterprise networks.  While it is technically possible to install software in a user's folder, this causes network administrators to go into a hissy fit.  As a rule, all executable programs should reside in a read-only directory.  It violates a fundamental security protocol to do otherwise.  Spyware, in particular, only needs to tangle itself into a Mozilla executable to engage a user's system and compromise an entire network by capturing sensitive user data.

In networks that I have administered is a common practice to seek out and block rogue executables.  If Firefox is to a viable enterprise solution, it must operate only under the read-only restrictions of a protected "Program Files" folder (for Windows XP) or a protected "bin" folder in Linux.

Vista's advantage is that it now integrates the root password request common to Linux and BSD.  XP's major headache is that you have to mess around with the Loggoff/Logon as admin procedure in order to update Firefox.

How do you resolve that?  I proposed earlier that
a) We have no messages presented to a user account regarding updates.  This would eliminate the confusion encountered by everyone in my family when they see the Update messages that have absolutely no relevance to their work.  This is identical to the situations faced in an enterprise environment where 98% of the workforce should not concern itself with those messages.
b) Add a small, subliminal icon to the upper right corner which indicates an update is available.  It alerts the admins that an update is available, but it is simple enough not to gain much attention from an average user.  This is common with OpenOffice and has worked very well.  Admins initiate the update process in OO and it automatically updates the user folders without one word to a user account.

As a final note, however, I must affirm that I support the idea of having the option to install a program in the user's Application folder.  Network admins can easily delete executables if necessary, but under many circumstances the option of installing programs in your personal folder is necessary as a temporary work-around.  I teach at a University that has typically been very restrictive about applications that can be added to a system and many of my students work in environments that are similarly controlled.  But many net admins allow for exceptions, of which I have often requested: Python and PuTTY are two examples that come to mind.

Comment 46

[Jesse Ruderman]

IMO, the default should be to inform users that Firefox needs to be updated, with a dialog.  System administrators who manage updates themselves should be able to turn that off (and perhaps make a subtle non-dialog notification appear), but the default should not be made insecure just to make enterprise deployment take one fewer step.

Comment 47

[Bud Huber]

I have just experienced this "bug" (a non-priv user getting automatic download of a new version but not being able to install). After reading all of the above, this is becoming frustrating to me. Why should we confuse non-priv users (who are typically challenged as well as not interested in techie stuff) with a situation in which they don't know what to do nor where to turn. Consider a hotel guest in Central America going to the lobby computer system (with only non-priv status) at 3:00AM, and then being confronted with an 'unable to install' error message. They don't know what to do nor where to turn for help. This is not a made up situation, but actually happened.

Are we to wait until Firefox 3? (Which is what I understand from the above, or perhaps I am misinterpreting.)

Comment 48

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Please stop bugspam. As you can see above the patch is awaiting approval for 1.8.0.7 which will fix the issue for Firefox 2.0.0.7.

Comment 49

[Perry]

Henrik, what is "bugspam"? (dictionary.reference.com had no entry for it.)

Comment 50

[Henrik Skupin [:whimboo][⌚️UTC+1]]

If anyone would have read the comments in that bug before adding a new comment they would have seen that it will be fixed for 2.0.0.7 (See comment 37 and given approval flag 1.8.1.7). We don't need more useless comments that it is not fixed for 2.0.0.6. At least you have to watch for the keywords fixed1.8.1.7 or verified1.8.1.7. If one of them are entered it will be fixed for the upcoming Firefox release. 

Comment 51

[Perry]

Henrik, you posted, but you ignored my question. 

What is bugspam?

Is that a way of insulting all of us that are trying to post and give feedback (is it calling us all spammers?) and is the implication that you do not want any of the public giving feedback? If so, you should just come out and say so, instead of using words not found in any dictionary, and referring to some weird keywords that noone knows what they mean except developers.

Comment 52

[Carsten Book [:Tomcat]]

(In reply to comment #51)
> Henrik, you posted, but you ignored my question. 
> 
> What is bugspam?

First, Bugzilla is no discussion forum and this is getting a little off-topic now. For Discussions are the Forums or the irc Channels are much better. 

For every comment you make in bugzilla, people that are cc'd on this bug or watching the components etc get emails about the change/comment. So in this case a lot of people get email.

Because this Bug here is fixed on trunk builds and will be fixed in 2.0.0.7 there is no need to add more comments to this bug or requests when this is fixed etc.. like comment #47 as example or that this bug is still seen in Firefox 2.0.0.6 

A better word instead of bugspam is maybe bugzilla bugmail spam. 

Comment 57

[Daniel Veditz [:dveditz]]

Comment on attachment 270978 [details] [diff] [review]
patch

approved for 1.8.1.7, a=dveditz for release-drivers

Comment 58

[(not reading, please use [e-mail] instead)]

working on landing this today.

Comment 59

[(not reading, please use [e-mail] instead)]

fixed on the MOZILLA_1_8_BRANCH.

Checking in nsUpdateService.js.in;
/cvsroot/mozilla/toolkit/mozapps/update/src/nsUpdateService.js.in,v  <--  nsUpda
teService.js.in
new revision: 1.77.2.50; previous revision: 1.77.2.49
done

Comment 60

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.7 using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7pre) Gecko/2007091003 BonEcho/2.0.0.7pre - the option for software updates is disabled for limited user on XP. On Vista, User get the UAC Dialog. This is expected see comment #33

Adding verified keyword.

Comment 64

[Joachim Kluge]

(In reply to comment #60)
> the option for software
> updates is disabled for limited user on XP.

Does this mean there is no notification for limited users on XP? Can't check because I'm on GNU/Linux.

Comment 65

[Eric Niewoehner]

This issue has a parallel track under 374900 and I said my piece there.  But this problem is not yet fixed.  I appreciate, however, that this bug has received a higher priority.

Comment 66

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Eric, what isn't already fixed? Users without write access to the application folder cannot even check for updates.

The only problem I can see is if already downloaded update packages are stored within the user local settings some times before and isn't deleted. In that case the update process doesn't check if the user has write access and starts the update. But isn't this already covered by bug 374900?

Comment 67

[Eric Niewoehner]

Yes -- 374900 does cover this, which explains my sporadic attention to this thread.

I believe the solution to this vexing problem is simply reinstalling Firefox.  I haven't observed any problems for a while on the XP station.  I'll certainly repost a comment if I see a reoccurrence of the problem.  

Comment 69

[Aakash Desai [:aakashd]]

I dont think this really fits into the litmus testgroup we've created for major updates (from 3.0 to 3.5) due to the complexity of the bug report as well as its age. Marking this as in-litmus-

Comment 70

[Henrik Skupin [:whimboo][⌚️UTC+1]]

It's not only for major updates. It's for each update users will receive. Until Windows XP is the most used OS I would really see a Litmus test for it. I don't think that it can be tested with an automated test. Rob, any objections from your side?