Closed Bug 318855 Opened 19 years ago Closed 8 years ago

App update should provide method to update when the user doesn't have privileges

Categories

(Toolkit :: Application Update, defect, P3)

Product:
Toolkit
Component:
Application Update
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -
status1.9.1 --- wanted

People

(Reporter: crawdad, Unassigned)

References

Details

(Keywords: sec-want, Whiteboard: [sg:want P2][parity-opera][parity-safari])

Attachments

(2 files, 4 obsolete files)

Updated screenshot to comments
24.69 KB, image/png
beltzner
: ui-review+
Details
strings rev2 (checked in)
1.82 KB, patch
beltzner
: review+
beltzner
: approval1.9.1+
dveditz
: approval1.9.0.9-
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Menu item "Help/Check for Updates" is greyed out, not clickable.


Reproducible: Always

Steps to Reproduce:
1.Click Tools
2.Note that "Check for Updates" is greyed out.


Actual Results:  
Unable to check for updates.

Expected Results:  
Able to check for updates.
Are you using any 3rd party theme ?
No 3rd-party themes installed.
Only 3rd-party stuff are a few extensions.
Extension list reads: Talkback, DOM inspector, Tidy HTML Validator, Adblock, BugMeNot, and WebDeveloper.
Do you have write access to the Firefox install directory ? Software Update is disabled if that is not true.
No, I don't. And - doesn't that seem a dangerous requirement?
I would strongly recommend that:
1 - the check be performed, then 
2 - prompt for the root passwd and use su / sudo to perform the actual update itself.
Summary: "Help/Check for Updates" greyed out → 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)
Still performing the check could be a good idea, but only in limited cases. 

For Linux, Software Update (SU) is only appropriate for Firefox (or Thunderbird) downloaded from mozilla.com and installed manually by the user. Any distribution compiled version won't work with mozilla.com's binary/incremental patches, and will fall back to the full update. The file locations may differ so that the full update may also fail. I suspect most distro's would prefer to disable the update check and keep updates in-house by providing their own patches or packages. 

Similarly for corporate situations on Windows, the System Admins probably don't want the users being nagged about updates. 

In both cases, SU is currently disabled for a user without write access to the Firefox install dir. The preference app.update.enabled can be set to false to disable SU, but that requires an active change by anyone in those situations now that 1.5 has been released.

The only case I can think of where you'd want to prompt for a password, is where a mozilla.com binary has been installed systemwide, and the user has root/Administrator access but usually runs with limited rights. The former is going to be uncommon on Linux, and the latter is (sadly) uncommon on Windows.

Where abouts do you fit into this scheme ? Comments ?
>The only case I can think of where you'd want to prompt for a 
>password, is where a mozilla.com binary has been installed systemwide, 
>and the user has root/Administrator access but usually runs with 
>limited rights. The former is going to be uncommon on Linux, 
>and the latter is (sadly) uncommon on Windows.

>Where abouts do you fit into this scheme ? Comments ?

You have described my situation exactly!
I run Suse Linux.
I have a single install of a mozilla.com binary to serve my various accounts and multiple users.
I do NOT RUN AS ROOT!! but when prompted for the root PW by Moz updater, would be able to supply it.
I think that this is NOT an uncommon situation among Linux users.

Practically speaking, if using "su" or "sudo" is awkward, simply checking for the update would let me know that I should log into the root account long enough to perform the update...
Yes, please allow checking for updates at least.
It is not necessary to do the actual install, as the required action may be dependant on whether the FF package was installed from mozilla.com or delivered by the Linux distribution.
But please allow for activating the check for a new version so that one at least know that there may be a critical update and that one has to take some action, whatever this may be.

*** Bug 325646 has been marked as a duplicate of this bug. ***
OS: Linux → All
Hardware: PC → All
You guys might find this document helpful for administrating Linux systems with shared copies of FF:

http://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file

I agree that it would be nice to still provide a means for users to check for available updates.  That could probably be written as an extension to FF 1.5 fairly easily FWIW.
Two notes:

1. We should also prompt for root on OSX
2. We should show users on w32 a dialog that says

   "An update for Firefox is available. Please contact your system administrator
   to have this update installed."

(I seem to recall that there already was a bug for 2? am I misremembering? nominating this one for blocking just in case, as I don't want to lose track of it)
Flags: blocking-firefox2?
This is really more of a nice-to-have than a blocker.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox2? → blocking-firefox2-
I'm marking this bug as [sg:want P2] because

* on many multi-user systems, and on some single-user systems where the user has chosen not to use a root account, this often means Firefox just won't get updated.

* making users choose between two security measures (automatic browser updates and using a non-root account) isn't too hot.
Whiteboard: [sg:want P2]
The big challenge in trying to enable "update via root" is figuring out how to fail gracefully when FF is being used by another user.
(In reply to comment #11)
> This is really more of a nice-to-have than a blocker.
> 

For me, the "and, on Linux, prompt for root password" part would not be a blocker as well. I'm not sure if I would even ask for that. 

But the ""Help/Check for Updates" should not be disabled, but should perform check anyway" part is far more than just a nice-to-have thing.

I'm running FF as normal user, and by that don't even get notified of any updates!

I would very much apreciate if at least that notifying part for non-root users would be a blocker for 2.0.
In my eyes it would be ridiculous if FF 2.0 still would not be able to at least _notify_ non-root users of (critical) updates but ask them to follow the press to get aware of new FF versions.

Once I know of a new update it would be ok for me to change to root user for the upgrade itself.
Yes, that sounds like a good first step to me as well.  As for Mac OSX, I doubt many users run a readonly copy of FF.  Of course, I'm just guessing there.
*** Bug 332161 has been marked as a duplicate of this bug. ***
Blocks: 309367
*** Bug 335541 has been marked as a duplicate of this bug. ***
Just an addition from my bug 335541, which was rightly marked as a duplicate:

I confirm that Help > Check for Updates is disabled, and it should be noted that paradoxically, Tools > Options > Advanced > Update > "Automatically check for updates to" > Firefox is disabled but checked. Unchecked would be closer to the actual behaviour.

In bug 317703 there are comments saying that guest users should not be bothered
with anything even remotely connected to administration. While I want to stay
out of the argument whether update management should be a system-wide setting
rather than account-wide or even profile-wide, I think that a dialog with just a
confirmation button and a suggestion to let an administrator run Firefox should
be OK. And users should be able to use Help > Check for updates if they want to.

*** Bug 336494 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3)
Gecko/20060426 Firefox/1.5.0.3

I would argue that the severity of this bug should be elivated back to normal.
Security minded users do run in non-admin accounts for their normal daily and
web surfing activity.  If you follow the approach other OSX applications
employ, then the user would be prompted for the administrator UID/PW when
installation is required.  Users should be able to control this by their
preferences.

A related symptom, if a non-admin user unchecks check for updates for "Firefox"
the check box becomes grayed out and cannot be rechecked.  This inconsistent
behavior leads to confusion for the user.
*** Bug 342500 has been marked as a duplicate of this bug. ***
There really is no reason to prevent people from checking for updates, even if we can't do the install. If they want to click that menu item then they are in effect asking "Am I Safe?" -- we owe them a yes or no answer to the best of our knowledge, even if we can't offer to do the install.

Some users might even interpret the disabled item as meaning they are fully up to date and assume themselves into a dangerously vulnerable state.

(I also think we should continue to do the auto-update check and actively inform people they need an update, but I guess that's a different bug)
*** Bug 343329 has been marked as a duplicate of this bug. ***
I think you'll be able to prompt for a more privileged account on Windows Vista, where UAC will be the default.
Is there a way to force an unattended update (and then exit) from the command line?  Ideally a scheduled task (cron, etc.) could be run with Admin/root privs that runs "firefox -update" or something.  This would allow admins to schedule updates as needed without having the unpriviledged users be attentive to it.

(In reply to comment #24)
> I think you'll be able to prompt for a more privileged account on Windows
> Vista, where UAC will be the default.
> 

You can do this in winXP as well.
I just say....let them do the check - but not the update (maybe the "update" button can be grayed)
If Firefox will get that feature, it would be able to trigger "runas /user:administrator "firefox.exe --installupdates". I guess there is better way by using Windows API rather than runas.exe which will be able to prompt to administrative local user or domain administrative user, but runas.exe is a good start.

As for Linux, I would like that the update will trigger "sudo firefox --installupdates". 
As I see it there are 4 different cases to consider when you run Firefox:
(1) You are the administrator and you are running with administrative privilege
(2) You are the administrator but you are running under an unprivileged account
(3) You are using a distro version of Firefox, so Redhat or SuSE or
someone is responsible for providing updates
(4) You are an unprivileged user, do not know the root password and
rely on someone else to install updates (perhaps someone you know or
perhaps someone in a far-off computer department).

Case 1 ought to be rare, but sadly is very common. The current
auto-update scheme works fine for it. 

In case 3 you probably don't want any messages, so you want the distributor to
be able to disable the auto-update scheme. 

Prompting for the root password would be a reasonable option for case
2, but would be a bad idea for case 4. We should focus on case 4,
because these guys are exactly the people we don't want to confuse
with unhelpful messages. 

The simplest solution would be to generate a message saying something
like "A newer version of Firefox is available but you do not have
write access to the installation directory. Contact your system
administrator." 

A more sophisticated solution could include a button marked "I am the
system administrator".

The current situation is definitely bad because it allows critical
security updates to pass unnoticed.

The change to checking for updates, even if the user does not have administrative privileges, is a BACKWARDS STEP FOR WINDOWS USERS IN AN ENTERPRISE ENVIRONMENT.

Please either return this to previous (no notification, users can't check for updates), or make the dialog that the check returns aware that it can't perform an update (and that download and update is not the prompted option as it is currently) and provides information like in comment #10. Perhaps the prefs UI needs to include an option to 'notify only' in addition to ask and download+update.

I recognise that Linux/MacOSX/Vista may all have the ability to sudo/UAC for privileges, but this is unlikely in an Enterprise Windows environment - maybe there could be a pref app.update.escalatePrivileges to be true to allow a sudo-type option.

Note: this applies to Thunderbird 2 as well.
Perhaps the pref should have three settings:

* notify, and prompt the user to escalate their privileges
* notify, and prompt the user to contact their sysadmin
* do nothing

The first should be the default for users who control their own systems (which is presumably most individual Firefox users), and enterprise users, who will probably want one of the two other options, depending on their level of in-house control-freakery.

Perhaps a compromise option might be to allow a fourth option:

* notify, and prompt the user to contact their sysadmin, but don't do this until X days have elapsed after the initial warning

to allow company IT departments a grace period for testing, while still providing end-users a safety net if their IT department drops the ball.


I think there is a major annoyance connected with this bug. I was able to observe this behavior in Windows (XP Pro SP2).

Scenario:
You are logged in as a normal user with restricted rights and Firefox detects an update and downloads it. The user clicks on install but the installation fails because of missing rights. The user calls for the admin or logs in as admin (if he has the rights). The admin installs the updates successfully. The user logs in again, starts Firefox but Firefox does not recognize that updates have been installed already and tries to download / install again. Error dialogbox appears (some files could not be updated because of missing rights ...) every time the user starts Firefox. Only option in the menu is to install the updates (previous versions still also offered check for updates and this solved the problem, but this option is no more available). This is the point where the users become annoyed and change their browser to something else ...

I think the problem is, that the update mechanism is profile dependent but the installation is system wide. Probably Firefox should check the installed version before it tries to update anything.
I can confim this behaviour (#31). 
But if firefox first checks if the rights are sufficient to make an update and otherwise only shows an information about an available update - then this problem should be solved too.
Before this goes too long, it sounds like there should several breakout bugs.

The menu disabled issue is completely different than the prompt for password discussion. 

My concern about the greyed menu item is that it doesn't telll you why it is greyed. I assumed i had some kind of connectivity failure, because the disabled action was checking for updates.

On a related note, if an when this bug is broken up, I suggest that you the login-for-upgrade bugs per-platform. Mac OS X is similar to Linux, but the rules for application permissions are different. 
I agree. But even the menu disabled issue is missing the fundamental point which is that users are not informed when updates are available...a user should not be expected to check for updates nor subscribe to Bugtraq, they should be *told* that updates are available. This is a security bug and should be regarded as serious. 

Fortunately it should be much easier to fix than making the update mechanism easier for them. Probably the hardest thing is drafting the help text to cater for the various situations without alarming unsophisticated users.


Switched first 2 clauses of Summary so that the thing people are likely to search for is in the first 64 characters - after much searching I only found this bug to explain why the "check for updates" option was disabled via its duplicate.

Now I just need to figure out exactly which part of my installation is no longer writeable and why, as all previous updates worked just fine...

To add to the debate, I would agree that ordinary users need to be informed that an update is available, even if they are incapable of installing it themselves. The alert could possibly include a "Don't tell me again for this version" option or similar, and users that REALLY don't want to know about new versions could turn the option to check for them off.

I'm also a little confused, as this "feature" should have prevented a problem I saw on another machine... but that's a different bug - I'll see if I can find that already now!
Summary: 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) → "Help/Check for Updates" should not be disabled when Firefox doesn't have write access to itself, but should perform check anyway (and, on Linux, prompt for root password)
(In reply to comment #31)
> I think there is a major annoyance connected with this bug. I was able to
> observe this behavior in Windows (XP Pro SP2).
> 
> Scenario:
> You are logged in as a normal user with restricted rights and Firefox detects
> an update and downloads it. The user clicks on install but the installation
> fails because of missing rights. The user calls for the admin or logs in as
> admin (if he has the rights). The admin installs the updates successfully. The
> user logs in again, starts Firefox but Firefox does not recognize that updates
> have been installed already and tries to download / install again. Error
> dialogbox appears (some files could not be updated because of missing rights
> ...) every time the user starts Firefox. Only option in the menu is to install
> the updates (previous versions still also offered check for updates and this
> solved the problem, but this option is no more available). This is the point
> where the users become annoyed and change their browser to something else ...
> 
> I think the problem is, that the update mechanism is profile dependent but the
> installation is system wide. Probably Firefox should check the installed
> version before it tries to update anything.
> 

This is precisely the problem which I just logged in to report. This isn't a bug, just an "annoyance"? I don't have write access to "\Program Files\Mozilla Firefox", so why does it download and attempt to install updates, by default? This is the first time that installing the updates as Administrator didn't solve the problem for me though.

I don't mind an alertbox or something letting me know an update is available, but it shouldn't be downloading it, let alone attempting to install, without first checking if I have write access.

I guess this isn't the correct venue to ask for a workaround, but if someone wants to save me the effort of searching by posting one here, it would be much appreciated.

I know I could just use cacls to give myself write access, but every time I do something like that I'm defeating the purpose of running as a limited user.
(In reply to comment #36)
> (In reply to comment #31)
> > I think there is a major annoyance connected with this bug. I was able to
> > observe this behavior in Windows (XP Pro SP2).
> > 
> > Scenario:

[...]

> This is precisely the problem which I just logged in to report. This isn't a
> bug, just an "annoyance"? I don't have write access to "\Program Files\Mozilla
> Firefox", so why does it download and attempt to install updates, by default?
> This is the first time that installing the updates as Administrator didn't
> solve the problem for me though.

[...]

Probably I was not precise enough. I meant this is a bug which implies a major annoyance. The update was installed successfully by admin. Now there is only this nasty box which needs to be clicked away always.

With previous versions, I was able to select check for update. This check corrected the problem -> Update installed, nasty box away. Now this check option is no more available and firefox does not recognize, that the new version is installed already.
This is not only true for Firefox, but also for Thunderbird (maybe the hole mozilla suite).

One way to solve this on Windows XP for normal users is to empty the directory:
%HOMEPATH%\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox or the counter part for Thunderbird and than disable the check for updates.
Please make it happen that a non privilidged user gets notifications. Otherwise there will be very old Firefox installations which can be exploited. This won't lead to bug #1 fixed (ok Firefox is not Ubuntu: Bug #1 does not exist.)
I was originally watching this bug as I had FF installed on my OSX systems in a shared applications folder and only the administrator who installed was able to check or get update notifications.

Even other admins on the same computer could not check for updates or receive update notifications.

WORK-AROUND:  My work around for this problem was to uninstall FF from the shared application folder.....and install it in EACH users own home folder....yes this means duplicate files/applications...but at least EACH ADMIN gets update notifications and can update FF...:)


(In reply to comment #40)
> Please make it happen that a non privilidged user gets notifications. Otherwise
> there will be very old Firefox installations which can be exploited. This won't
> lead to bug #1 fixed (ok Firefox is not Ubuntu: Bug #1 does not exist.)

Yes, _please_.
I'm using it on a single user Linux box and find it _very_ annoying that I cannot configure FF to notify me of updates - and honestly I do not understand the reasoning here, if any.
I have no problems to login as root to do the actual update, but please allow me to get those bloody notifications.

Thanks



I disagree about bug 407875 being a duplicate. This bug is an enhancement request, whereas bug 407875 is a major security bug.

Anyway I don't want to get into an argument, I just thought submitting the new bug might help solve the problem.  
(In reply to comment #25)
> Is there a way to force an unattended update (and then exit) from the command
> line?  Ideally a scheduled task (cron, etc.) could be run with Admin/root privs
> that runs "firefox -update" or something.  This would allow admins to schedule
> updates as needed without having the unpriviledged users be attentive to it.
> 

No, I do not think that this is a good idea. Just ALERT the unprivileged user. Then there will be two cases:
Case I is when the unprivileged user is allowed to turn on the Administrator privilege (in Windows XP), and I include myself. I can then install the update in the usual way.
Case II occurs in certain enterprise installations (and others). For security reasons, the ordinary user is not allowed to turn on the Administrator privilege. It is then appropriate to alert the user and say, "A new version of Firefox is available and needs to be installed by an administrator." and repeat this every two or three days. What is the alternative? Keeping the update SECRET?

And no, the new version cannot be installed in Windows XP with the Administrator privilege turned off. (The terminology is different in Linux.)

Thomas L. Jones, PhD, Computer Science
DrJones at alum dot MIT dot edu
Flags: wanted1.8.1.x+
Flags: blocking-firefox3?
Depends on: 407875
> Case II occurs in certain enterprise installations (and others). For security
> reasons, the ordinary user is not allowed to turn on the Administrator
> privilege. It is then appropriate to alert the user and say, "A new version of
> Firefox is available and needs to be installed by an administrator." and repeat
> this every two or three days. What is the alternative? Keeping the update
> SECRET?

Administrators at a large organization would probably not appreciate receiving tens or hundreds of support tickets requesting the Firefox update, within only a few minutes of the time they themselves are alerted to the update.


If that's a problem they can get roughly a week's notice by watching the mozilla.announce.prerelease newsgroup or signing up for release-candidate updates.
(In reply to comment #47)
> If that's a problem they can get roughly a week's notice by watching the
> mozilla.announce.prerelease newsgroup or signing up for release-candidate
> updates.

Do you then sit there 24/7 around the projected release date watching for the actual release, or do you risk globally installing a release-candidate which may in fact require revision prior to release due to last minute bugs or security issues which come to light?

A solution I think would be satisfactory is for there to be two configuration options.  The first, if enabled, would in effect indicate "Although running as an ordinary user I am able to gain administrator privileges".  Then only users with this option set (or users actually running with administrator privileges) have the update notice automatically displayed.  The second option would come into play only if the first option were not enabled.  It would either disable (gray out) the "Check for updates" menu item, or enable it and provide a message like "An update is available which your administrator will install shortly".

The individual who administers his/her own workstation would set the first option.  The administrator of a small number of workstations could disable the first and enable the second option.  The administrators of a large number of workstations would probably choose to disable both options.


Much of the problem is due to defective default settings. If a Firefox user wants to click Help > Check for updates, that is a good starting point. If the organization's policy is that prudent users [1] are not to check for updates, let the IT department handle it. Circulate a memo. Criticize users who violate the policy. The IT department will install the updates when it gets time. Here is the BAD idea: Electronically block the process of checking for updates by prudent users, perhaps by graying out the relevant check boxes.

[1] The phrase "prudent users" is here defined as users who run with limited privileges for day-to-day surfing.

Tom Jones

There is a workaround, although it is a clunky one. The users should get into the habit of launching the following hyperlink:

http://www.mozilla.com/en-US/ (for English-speaking residents of the U.S.)

The hyperlink may be launched with the aid of a bookmark.

This will display the latest version of Firefox. As of today, December 27, 2007, it is version 2.0.0.11 

Thomas Jones

(In reply to comment #49)
> Much of the problem is due to defective default settings. If a Firefox user
> wants to click Help > Check for updates, that is a good starting point. If the
> organization's policy is that prudent users [1] are not to check for updates,
> let the IT department handle it. Circulate a memo. Criticize users who violate
> the policy. The IT department will install the updates when it gets time. Here
> is the BAD idea: Electronically block the process of checking for updates by
> prudent users, perhaps by graying out the relevant check boxes.
> 
> [1] The phrase "prudent users" is here defined as users who run with limited
> privileges for day-to-day surfing.
> 
> Tom Jones
> 

I don't disagree with you.  However I suspect input from others who do disagree is what led to the grayed-out menu item in the first place, and that including   the grayed-out menu item as one option could persuade these others to not oppose the other options I suggested in Comment #48.

(Bug number 318855)

I think we should focus on meeting the needs of users who usually run unprivileged for security reasons, but have access to privileges as needed to fetch Firefox updates, etc. Assume that these users do their own updates, as distinguished from installations where there is an IT department which makes the updates. Especially, it is important that these users be able to check for the appearance of updates.

The issues with 2.0.0.11 can be stated like this: The privilege switched-on vs. switched-off distinction is being used as a rough and ready way of predicting whether or not a user makes his or her own updates.

Also see replies number 48 and 51.

Tom Jones
 
(In reply to comment #12)
> I'm marking this bug as [sg:want P2] because
> 
> * on many multi-user systems, and on some single-user systems where the user
> has chosen not to use a root account, this often means Firefox just won't get
> updated.
> 
> * making users choose between two security measures (automatic browser updates
> and using a non-root account) isn't too hot.
> 
Suppose a Windows user is running unprivileged for security reasons. Then automatic browser updates are not doable. Instead, what are doable are automatic alerts about the release of updates. Sometimes the better is the enemy of the good. However, you are of course right about not making users choose between two security measure.

Not going to block on this, but it is wanted.  We'll look at getting this early in the next release cycle.
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-
This highly damaging bug seems hardly worth commenting on. It was first reported more than two years ago (December 2, 2005). It is still considered an enhancement and is assigned to nobody. It has a simple fix, but the Firefox people aren't interested.

Tom
Thomas L. Jones, PhD, Computer Science

This highly damaging bug seems hardly worth commenting on. It was first reported more than two years ago (December 2, 2005). It is still considered an enhancement and is assigned to nobody. It has a simple fix, but the Firefox people aren't interested.

Tom
Thomas L. Jones, PhD, Computer Science
Severity: enhancement → major
And yet, you commented twice!

If you have a simple fix, feel free to attach a patch.  Otherwise you are just making stuff up.
If you feel that this is not the proper venue for submitting this comment, please preface your remarks by describing what you feel is the proper venue. I am definitely not making stuff up. I have already submitted an English-language description of the fix. As far as creating a patch is concerned, it is unclear that I would have the necessary skills to do this. I might well need a collabarator. Anyway, I will meet you halfway.

To start the ball rolling, you spoke of a "patch." Question: Would this patch be coded in a computer language like C or C++? Question 2: Would I need to learn CVS? I did look at a writeup about creating a patch.

Thomas Jones

(In reply to comment #31)
> You are logged in as a normal user with restricted rights and Firefox detects
> an update and downloads it. The user clicks on install but the installation
> fails because of missing rights.

From Tom Jones:

There is a defective default setting involved. Upon visiting the update page [1], one sees a radio button with two settings. (1) Ask me what to do; and (2) Automatically download and  install the program. (2) is the default setting. If the user is running in a LUA, it creates problems, since the user has not been given a chance to first switch to an administrative account.

Instead, "Ask me what to do" should be the default.
(In reply to comment #59)> 
> To start the ball rolling, you spoke of a "patch." Question: Would this patch
> be coded in a computer language like C or C++? Question 2: Would I need to
> learn CVS? I did look at a writeup about creating a patch.
> 
> Thomas Jones
> 

Well I can at least answer these questions: 1) Yes. 2) Yes (but it's relatively easy compared to learning a "computer language").
Flags: blocking-firefox3.1?
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Priority: -- → P3
Target Milestone: --- → Firefox 3.1
Suggested solution:

- Re-enable 'Check for Updates...' (see Bug 407875)

- Set 'When updates to Firefox are found' to 'Ask me what I want to do' by default (see Comment #60; separate bug should be opened)
  (There are other reasons why this default should change, but I won't go into that now.)

- Administrators of networks can disable automatic update checks to prevent large numbers of users emailing them about available updates.

- It should be possible distinguish between critical and non-critical updates, with preferences. By default, non-privileged users should only be notified of critical/security-related updates.

- If the user is able to write to the appropriate files in the install directory(s), the options in the notification window should be as follows:

[1] Download Update | [2] Download and Install Update | [3] Ignore this Update

1. User is prompted for download directory, defaults to somewhere under his/her profile directory. Should be one file, not multiple (for easy backup).

2. Same as [1], after which the file is executed, and setup occurs.

3. User is able to ignore certain updates, but ignoring critical updates is strongly discouraged.

- If the user is *unable* to write to the appropriate files in the install directory(s), the prompt should inform the user that in order to install the updates, he/she requires administrative privileges, and if the 'Download and Install Update' option is selected, he/she will be prompted for the appropriate credentials at the time of installation. The same three options will be available.

- Option 2 for unprivileged users could be handled with an OS-specific privilege elevation or user-switching mechanism (runas on XP, su/sudo on Linux, etc.)

- Some users (myself included), use software such as MakeMeAdmin or RunAsAdmin to temporarily elevate their privileges (i.e. they obtain administrative permissions temporarily and switching to an administrator account is unnecessary). In these cases, the option to download the update could be selected, and they could run the update file manually with these elevated privileges. Alternatively, the 'Download and Install Update' option could use similar techniques, and the update process could be automatic.

Thoughts?
The menu was not disabled in Vista x64 SP1 (32bit FF2) - hence this is a regression in FF3 over FF2 behaviour.

Prehaps there needs to be a serparate bug for the regression as the original bug is pre FF3 yet the check for updates was checking for updates in FF2 on vista in a non privelidged account.
Keywords: regression
James, if it wasn't disabled in FF2 then it should have been and that would be a different bug... this bug is not a regression as it was designed to behave this way.
Keywords: regression
Product: Firefox → Toolkit
any advance for this ?

i have not read the whole thread but i have the same problem on macosx 10.5 with firefox 3 as non-admin user.
i don't have the option to check (not present in menu or preferences) and the automatic check never say anything to me, no message or something else.

i think at leas this point (not the elevation of privilege) is really important for anyone who cares about security ...

i agree with Glenn proposal.

thanks
agreed with glen with one change:

perhaps it would be possible for an unprivileged user to download some kind of wrapper/alternate executable to their ~ directory which will be run instead.  That way the unprivileged user can work with an updated firefox even when the admins don't want to update.

<< 
this would also be very useful when the admins used to allow installation of programs but changed over to a lock-down system. 

For Windows this depends on bug 437349
Depends on: 437349
From Tom:

I don't pretend to know when Firefox has access to itself or the consequences of having such access or not having it. In my own computer, Help/Check for updates will work in my administrative account, but not in the hardened Limited User Account, which has the administrator privilege switched off for security reasons.

Here is what I would like to see done: If a new version of FF appears:

Case I: The user is running under an administrative account: The user would be alerted in the usual way.

Case IIa: The user is running under a Limited User Account. He or she would be alerted as usual.

Case IIb: This applies to a public library or an enterprise installation. The IT department would be able to broadcast a message inhibiting the alerts to the users. That way we would not have a zillion public library patrons complaining to the IT department.

Tom
As a non-root Linux desktop user with a mozilla.com build for Firefox installed system wide,  it makes no sense for me to run Firefox as root simply to check if any updates are available.  Firefox should be able to atleast check and inform the user if any updates are available. 

Also it makes more sense to even download the update as a non-root user instead of accessing the internet with root privileges.

It makes more sense from security perspective too for Firefox to:
1) Let the non-root user check if any updates are available.
2) Prompt the non-root user if he/she wants to download the update.
3) If the non-root user confirms, download the update as non-root user.
4) Prompt for root password after the download is complete to install the update.
5) If the root password is correct, install the update as root user and then
   prompt to restart Firefox.
6) Restart Firefox as non-root user.

- Hemant
As a non-root Linux desktop user with a mozilla.com build for Firefox installed system wide,  it makes no sense for me to run Firefox as root simply to check if any updates are available.  Firefox should be able to atleast check and inform the user if any updates are available. 

Also it makes more sense to even download the update as a non-root user instead of accessing the internet with root privileges.

It makes more sense from security perspective too for Firefox to:
1) Let the non-root user check if any updates are available.
2) Prompt the non-root user if he/she wants to download the update.
3) If the non-root user confirms, download the update as non-root user.
4) Prompt for root password after the download is complete to install the update.
5) If the root password is correct, install the update as root user and then
   prompt to restart Firefox.
6) Restart Firefox as non-root user.

- Hemant
(In reply to comment #71)

Yes, this is the correct approach for Linux.
In reply to comment #69, case IIb: I suppose "broadcast a message" should be "set a preference" (maybe a hidden one) at install time, to inhibit update-available messages to non-admins. Since new (library etc.) users can be signed in at any time, IIUC the non-Mozilla-default preference should be in some system-wise "default profile" or similar.
On second thought, I guess the preference already exists: Don't auto-check for updates.

If a non-admin user checks manually for updates, he might even get a "true" answer, but of course, unless (on Linux or Vista?) he can escalate his preferences, he wouldn't be able to apply the upgrade.
s/preferences/privileges/
Attached image screenshot (obsolete) — 
I almost forgot about the strings needed for this bug...
Attachment #354978 - Flags: ui-review?(beltzner)
Comment on attachment 354978 [details]
screenshot

Since this dialog will be used for a variety of potential permissions problems, I think we need to go pretty general with the message. We also need to put the actual URL out there, as they're going to have to download and install it from another account. Finally, if this is something a user with a sysadmin sees, it needs to be easy enough for them to communicate the relevant information.

I think the following works - it does assume that if someone logs in using another account and runs Firefox, they will also be able to check for updates again and have the update try a second time - hopefully that's right.

title = Unable to Update

message = A recommended security and stability update is available, but you do not have the system permissions required to install it. Please contact your system administrator, or try again from an account that has permission to install software on this computer.

You can always get the latest version of Firefox at http://www.getfirefox.com
Attachment #354978 - Flags: ui-review?(beltzner) → ui-review-
It would be slightly simpler to do the following where http://www.getfirefox.com is on the next line... would you be ok with it?

You can always get the latest version of Firefox at:
http://www.getfirefox.com
Attachment #354978 - Attachment is obsolete: true
Attachment #354985 - Flags: ui-review?(beltzner)
Attached image Updated screenshot to comments (obsolete) — 
This has the exact changes asked for... leaving both up for review in case the previous one is acceptable
Attachment #354986 - Flags: ui-review?(beltzner)
Why are we using getfirefox.com in the product? We use http://www.mozilla.com/firefox/ everywhere else...
Not in reference to comment #80 but I am planning on using a pref to store the url since it needs to be app specific.
(In reply to comment #80)
> Why are we using getfirefox.com in the product? We use
> http://www.mozilla.com/firefox/ everywhere else...

Because it's easier to remember, IMO, after logging out, logging in somewhere else, etc. Do you have a significant objection to using it?
Comment on attachment 354985 [details]
Updated screenshot to comments

it's fine on a separate line, yeah
Attachment #354985 - Flags: ui-review?(beltzner) → ui-review+
Attachment #354986 - Flags: ui-review?(beltzner)
Attached patch strings (obsolete) — — Splinter Review 
Mike, can I get your approvals on the strings to land on 1.9.1? Thanks
Attachment #354986 - Attachment is obsolete: true
Attachment #354989 - Flags: review?(beltzner)
Attachment #354989 - Flags: approval1.9.1?
Forgot to switch out Firefox for &brandShortName;
Attachment #354989 - Attachment is obsolete: true
Attachment #354990 - Flags: review?(beltzner)
Attachment #354990 - Flags: approval1.9.1?
Attachment #354989 - Flags: review?(beltzner)
Attachment #354989 - Flags: approval1.9.1?
We'll use the app.update.url.manual pref (I'll change it when this is further along) since it is already used for manual updating when all else has failed.
Comment on attachment 354990 [details] [diff] [review]
strings rev2 (checked in)

r+a191=beltzner
Attachment #354990 - Flags: review?(beltzner)
Attachment #354990 - Flags: review+
Attachment #354990 - Flags: approval1.9.1?
Attachment #354990 - Flags: approval1.9.1+
Comment on attachment 354990 [details] [diff] [review]
strings rev2 (checked in)

Strings pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/dce664edeace818dbf47c8a9b69a1fcd43217bc0

strings pushed to mozilla-1.9.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/10fbbb50ce31
Attachment #354990 - Attachment description: strings rev2 → strings rev2 (checked in)
(In reply to comment #88)
> (From update of attachment 354990 [details] [diff] [review])
> Strings pushed to mozilla-central
> http://hg.mozilla.org/mozilla-central/rev/dce664edeace818dbf47c8a9b69a1fcd43217bc0
...with 'Firefox' hardcoded
(In reply to comment #89)
> (In reply to comment #88)
> > (From update of attachment 354990 [details] [diff] [review] [details])
> > Strings pushed to mozilla-central
> > http://hg.mozilla.org/mozilla-central/rev/dce664edeace818dbf47c8a9b69a1fcd43217bc0
> ...with 'Firefox' hardcoded
Thanks for catching my screwup on the mozilla-central patch / push. I pushed the fix to mozilla-central and if we want to change the name on mozilla-central I'll do so when I implement the rest to fix this bug.
I still think that's a bad idea to change the content of a string without changing its name, even after really few hours: I translated this string in the lapse of time between the two commits, and I've caught this change by chance. 

BTW, I took a look at mxr.mozilla.org and it seems I'm the only one with this problem.
I agree and it will change on trunk when the bug is fixed on trunk
Whiteboard: [sg:want P2] → [sg:want P2][strings landed]
Are the strings actually in and translated here? Are we actually going to get this for 1.9.1?
(In reply to comment #94)
> Are the strings actually in and translated here?

Per comment 88, yes.

I guess this bug isn't late-l10n anymore after two months passed and beta 3 shipped.
Keywords: late-l10n
Comment on attachment 354990 [details] [diff] [review]
strings rev2 (checked in)

If we've gotten localizers to localize this for 1.9.1, then we should be able to pull that string along and push this (localized!) into 1.9.

I'm running:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7

And wasn't told about the update because of one these bugs, and I think this was among the bugs I'd have hit.
Attachment #354990 - Flags: approval1.9.0.9?
We should have a much stronger argument chain than that to take an l10n change on 1.9.0.x. This does break langpack compat, at least, which the install.rdf's of that won't indicate.

On top of backporting strings just being a huge hassle.
Comment on attachment 354990 [details] [diff] [review]
strings rev2 (checked in)

The 1.9.0 branch isn't going to take just a string change -- that's all the pain with none of the gain. If we get an actual _fix_ for the bug on the trunk _then_ we can evaluate whether it's appropriate or not, and at that time more of the strings will have been translated.
Attachment #354990 - Flags: approval1.9.0.9? → approval1.9.0.9-
I run Firefox on Windows as an unprivileged user.  If I have Firefox configured
to automatically check for updates, it should check and offer to download the
update when one is available (even though it cannot be automatically applied).

I cannot even manually check for updates from the Help menu.

In the VERY least, the Help menu option should link to the web page
with the latest version so I don't have to go hunting for it myself.
I would like to request this feature for the Windows build. Several months ago, I installed Firefox 3.0.1 onto a WinXP machine as "Administrator" so that all users could share the common installation. The users are all unprivileged, of course. However, I have recently checked this machine and found that it was *still* running Firefox 3.0.1 because no-one had known that Firefox needed updating!

It would have been a *big help* if Firefox had alerted one of the users that there was a newer version of Firefox available.
I don't know what the exact status is of the proposed fix, but certainly hope this does not get postponed only for a translation issue since this really is a very annoying problem.
I don't mind running firefox or thunderbird as an admin in order to download/deploy an update.
However, being obliged to regularly run firefox/thunderbird as an admin only to check for updates is a major annoyance, and causes security-related problems as illustrated by comment #100 for example (I would expect this to have a higher priority than P3 because of that).
Isn't it time this was handled? It's been years now. And now 3.5 is rolling out.

Is it really so hard to do the following?

1. Automatic check for update, if new version is available notify the user.
2. If the user is a limited user then inform them to either restart the browser as administrator or to notify their administrator.

As it is now when I've missed several security updates since the automatic update check fail to notify me.
It isn't until I read it on a news site (or check the mozilla site) that I'll know.

If Firefox is smart enough to disable/grey out the button it should be smart enough to simply state: "A update is available, please notify your administrator or restart Firefox under an administrator account!"

Even the dimmest user should understand what is going on, after all they probably installed it in th first place, if not, well they'll notify the person that did right? (dad/mom/network admin)

I use Vista, and with Windows 7 around the corner XP and older will quickly fade away. UAC stuff like this will become even more prominent and expected behavior.

The way it works now (3.5 RC3/Final?) is not a good design choice.
Even if the user can't do the update, they should still be informed there is one. It's the task of whomever is admin to actually do the update. And most good admins usually have a limited privileges user that is their "normal" user.

Heck, I don't even use the Admin/Normal combo user on Vista, I actually have a fully separate Normal user I use, so any system changes always require password controlled elevation.

Would be nice if this could be changed and implemented in the next 3.5.x maintenance update.
I'm running firefox without admin privileges (windows not linux) and I'm not notified when (security) updates for firefox are available.
This is an annoying! 
This bug is reported years ago for ff 1.5!!!
There is a uglily workaround, at least for Linux:

touch /path/to/firefox/update.test
mkdir -p /path/to/firefox/updates/0
touch /path/to/firefox/updates/0/update.test

I think this has to be redone, after every update.

Now, the update check works also under an unprivileged account.
Is there an add-on available, which checks for Firefox updates? Perhaps this would be a possible workaround until Mozilla provides a fix for this bug!
blocking2.0: --- → ?
status1.9.1: --- → wanted
Flags: blocking1.9.2?
Can't in good conscience block on this for Firefox 3.6 without Rob being the one to nominate it, but definitely want to see a fix.
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
I just updated Opera using a limited user account on Windows XP, and it worked perfectly. I was notified of the update, I clicked "Download and Install" (you can click "Remind Me Later" as well), it downloaded, asked me to restart to complete the installation, and when restarting, prompted for administrator credentials in order to perform the update, after which it started the new version of Opera (with limited privileges).

That's how it should be done.
When the Apple Software Updater finds a Safari update in a standard user account in Windows 7, it simply presents an install button with a UAC shield (indicating elevation will be required if you click it).

I really don't see the need for a window explaining that updating isn't possible, when in most cases it would be with an over-the-shoulder elevation prompt. If an enterprise admin doesn't want users to see update dialogs, there's app.update.enabled...
This bug constitutes a serious security risk. You guys have been making laughing stocks of yourselves by not making sure it was resolved ASAP. This bug was reported nearly four crazy years ago. What's up with you? Does security mean nothing to you? Are you asleep?
Fully ACK with comment #113. Not fixing such a serious bug over such a long time is ridiculous and embarrassing and renders the claim implausible that security has priority for Mozilla. There seem to be too many people with Mozilla who are permanently logged on as admin on their Windows systems and hence regard this bug as a minor issue. Shame on you!
Comment 111, comment 112, comment 113 and comment 114...read comment 110.  Mike Beltzner clearly states that a fix is wanted for this.  Someone needs to attach a patch that fixes this.  Until then this bug will still be open.  No further useless comments are needed and they will NOT help speed things along here.  Take it to the forums or the newsgroups if you want to try an advocate for a fix here.  You can even put up a bounty and someone not tied to Mozilla might be more willing to spend thier time to fix this.
So I read comment #110. 

Why can't Mike Beltzner "in good conscience block on this for Firefox 3.6 without Rob being the one to nominate it"? 

It's no good telling users to go here, do this. We've got our own lives to lead. I'm already giving up my time commenting here, more I cannot, in good conscience. I accept the Mozilla head honchos also have their lives to lead. However, if they can't fulfil their roles in Mozilla, then, sooner or later, Mozilla will fail. I think that's a simple enough statement of fact.
(In reply to comment #116)
> So I read comment #110. 
> Why can't Mike Beltzner "in good conscience block on this for Firefox 3.6
> without Rob being the one to nominate it"?
I can't answer for Mike but I can bet it is because Rob Strong is the toolkit sub-module owner of the application update code.
http://www.mozilla.org/projects/toolkit/review.html

In other words, Rob is in charge of that code.  Now don't take that as he is supposed to be the sole person that works on this code and is responsible for fixing every application update bug.
Forgive me, but I don't think comment 111 and mine were "useless". Isn't the fix wanted in comment 110 the one shown in attachment 354985 [details]? Or is the window in the screenshot only to be shown when a pref is toggled, and otherwise it will ask for elevation?

Comments 111 and 112 were supporting Firefox just elevating rather than displaying a failure message unnecessarily. They should also help in tagging this bug parity-opera and parity-safari.
Why was my comment deleted?!It says nearly the same as #113 but was written days BEFORE ... so why?!
(In reply to comment #118)
> Forgive me, but I don't think comment 111 and mine were "useless". 
Useless as in everybody that is CC'ed here know what the bug is about, what not fixing this bug means, and that a fix is still needed.

> Isn't the fix wanted in comment 110 the one shown in attachment 354985 [details]
> [details]? Or is the window in the screenshot only to be shown when a 
> pref is toggled, and otherwise it will ask for elevation?
Yes, it is (for now at least).  Just the strings were checked in because those are needed for localization.  Someone still needs to create a patch that detects this setup and then adds that screen with those strings used.

Added the parity-opera and safari to the whiteboard.  Just do that then, don't spam the bug with comments.  79 people are on the CC list and today alone have received eight emails from this bug alone.  People don't have to see dozens of emails of "me toos" and "fix this asap".  Plus, like I just had to do...devs have to read every single message and this takes time out of their day to read this whole bug and figure out exactly what is wanted and what needs to be done here.
Whiteboard: [sg:want P2][strings landed] → [sg:want P2][strings landed][parity-opera][parity-safari]
> 79 people are on the CC list and today alone have
> received eight emails from this bug alone.  People don't have to see dozens of
> emails of "me toos" and "fix this asap".  Plus, like I just had to do...devs
> have to read every single message and this takes time out of their day to read
> this whole bug and figure out exactly what is wanted and what needs to be done
> here.

Don't forget: This Bug has its 5. bithday in a few days, it is essential for peoble who want work responsible and careful with Firefox and Windows. Nothing happend because it seems like nobody is interestet on this bug (because the responsible people work with linux?) i don't know.

But maybe the people simply think they have to do something and awake them now? What else can the users do after 5 jears of waiting?
I am very interested in fixing this. I am also very busy and fixing this bug is not as easy as you seem to think it is. I am also very annoyed by useless comments that take me away from the other work I am trying to accomplish.

btw: I am not the only person that can fix this so by all means please take this bug on with the caveat that I will not respond to questions regarding how to fix this bug that don't show the person has at least made an effort to understand the different scenarios this needs to cover as well as the code since the people that ask questions without doing so have always in my experience not tried to actually fix the bug and it takes time away from the other work I am doing so it ends up being a total loss of time / effort.
I'd like to remind people to read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before commenting further.

The best way to ensure a bug is ignored is to to be uncivil and add useless comments.
Bug 407875 made it so Help -> Check for Updates is not disabled and we will notify of available updates and provide an url to get the update.

Changing summary to be about the remaining issue. Each platform has its own convention for accomplishing this and I will file bugs for Linux, Mac, and Windows that block this bug for the remaining work in this bug.
Summary: "Help/Check for Updates" should not be disabled when Firefox doesn't have write access to itself, but should perform check anyway (and, on Linux, prompt for root password) → App update should provide method to update when the user doesn't have privileges
Whiteboard: [sg:want P2][strings landed][parity-opera][parity-safari] → [sg:want P2][parity-opera][parity-safari]
Target Milestone: mozilla1.9.1 → ---
Looks like it has been regressed at least bug 530286 for the French locale.
Depends on: 530286
Keywords: late-l10n
Sorry, wrong bug.
No longer depends on: 530286
Keywords: late-l10n
Concerning Firefox on MacOSX:

Why not simply use the popular Sparkle framework from http://sparkle.andymatuschak.org/ for updating Firefox on the MacOSX platform even from a non-privileged user account (elevating permissions via system's prompt for an admin password when writing into /Applications), like many other applications on MacOSX incl. Camino Browser already do?

Or, alternatively to the Sparkle framework, using Google's Update engine framework from http://code.google.com/p/update-engine/ ?
This one has already been fixed, hasn't it? The other night, I was surfing away in my unprivileged account, following the familiar advice that one shouldn't do day-to-day surfing in administrative account. A little window came up and said that there was an update available for Firefox. I had no difficulty switching to the administrative account, then downloading and installing the update. Win XP.

A good job. Thanks to all who worked on it.

Tom Jones
No, what you are referring to is notification of an available update which is fixed and is bug 407875. This bug is tracking platform specific bugs for providing the ability to update when the user doesn't have privileges. Your welcome and thanks!
Blocks: 566242
blocking2.0: ? → -
If a user does not have privileges and cannot get privileges, he or she will need to alert someone who does. An example is patrons in a public library, assuming that the IT department hasn't already been alerted. In any case, the update will be installed into an Administrative account or not at all. For a library patron or other similar person to download and install the update: Nope. Won't work. Forget it.

Tom

Windows XP
For Windows either a Windows service or MSI patches can provide the ability to update for a user without privileges so no, we won't forget it. ;) The library scenario you outlined would of course be able to prevent updates but that doesn't mean we shouldn't provide the ability to update for a user without privileges.
(In reply to comment #131)
> If a user does not have privileges and cannot get privileges, he or she will
> need to alert someone who does. An example is patrons in a public library,
> assuming that the IT department hasn't already been alerted. In any case, the
> update will be installed into an Administrative account or not at all. For a
> library patron or other similar person to download and install the update:
> Nope. Won't work. Forget it.

In many many cases (maybe in most cases), your patron and the user with lower privileges are one and the same person. One person with two roles at the same time: he is standard user with reduced privileges for day-to-day use, and at the same time he is admin of his own computer with full admin privileges for system maintenance. And for this scenario, it would be a huge win, if this person would be able to update Firefox from his standard account environment (based on reduced privileges) WITHOUT changing his whole environment and logging himself into the Admins account and desktop to be able to update Firefox. For this scenario, it would be very helpful, if Firefox would be able to use the system's mechanism to elevate his rights at the right moment. Meaning: download the new Firefox into a local Temp-Directory and install it with privileged rights (Admin rights) into the correct and systemwide location after being asked from the system for the Admin's password and so granted the correct rights to do so.

That does function.
On MacOSX it is very common.
See also comment 127. Please integrate the Sparkle Framework into Firefox. Look at Camino (Camino uses the Sparkle Framework to solve this), look at other Applications (at least on the Mac) how they deal with this. It saves you a lot of work and helps to solve this issue (at least on the Mac).
Elevation of user rights is a good point. Just see http://kay-bruns.de/wp/software/surun/ for a reference.

Kind regards.
Access privileged functionality (for instance: application update) from a non-privileged application on Mac OS X:

Apple Developer Mac OS X Reference Library: BetterAuthorizationSample from http://developer.apple.com/library/mac/#samplecode/BetterAuthorizationSample/Introduction/Intro.html

Or use Sparkle from http://sparkle.andymatuschak.org/ (also used by Camino and many, many other third party applications on the Mac to allow a privileged application update from the role of a non-privileged user).
I'm really shocked that this is still sitting since 2006 with no fix or workaround.

IMNSHO the *very next release* of firefox should allow everyone to check for updates.  If the user does not have privileges, they should be told that the update is available but they do not have privileges to install it.  The auto-update check should work in the same fashion.

In lieu of a fix for this issue I'm looking to create my own notifier for updates, if anyone can help me decode the variables in the updateURL please contact danpritts at yahoo.
The current system as of 3.6 already allows users to check and be notified about an update when using an account that isn't able to apply updates. What we need to do in this bug's dependent bugs (each platform has significantly different methods for elevation) is provide a sane way to ask the user to elevate and if they are unable to (e.g. they don't have credentials or know of credentials that can apply an update) don't repeatedly ask the user to elevate and fallback to the current method of only letting them know there is an update available.
Attached file its good (obsolete) — 

    
  
Flags: wanted1.9.2+
Flags: wanted1.9.1+

    
  

        Attachment #554611 -
        Attachment is obsolete: true

        Attachment #554611 -
        Attachment is patch: false
Assignee: nobody → netzen

    
    

    
  
(In reply to Bob Vickers from comment #28)
> As I see it there are 4 different cases to consider when you run Firefox:
> (1) You are the admin running with admin privs
> (2) You are the admin running under an unprivileged account
> (3) You are using a distro version of Firefox, so Redhat or SuSE or
>     someone is responsible for providing updates
> (4) You are an unprivileged user, do not know the root password and
>     rely on someone else to install updates (perhaps someone you know
>     or perhaps someone in a far-off computer department).

Actually there are twice as many cases, because each of those cases should also be a different case based on whether the automatic check for updates pref was enabled or not.

I'll only address the Windows 7 scenario (with UADC enabled), since that is my main focus.

The way I have historically handled updates in my office when we were all on XP where all users run as 'Power User', which does allow them to be able to apply updates to Firefox and thunderbird (I'm a lone IT guy, anywhere from 40-60 users) is simple... I disable auto-updates on all computers but mine, when a new update becomes available, I wait until all of the extensions we use are updated (or I might just version bump them myself), then I update mine and test for a day or two... if all is well, I start walking around the office, ask the user for a minute, click Help > About Firefox (or Thunderbird), click 'Check for Updates', then apply the update. I can get everyone updated in a day or two with little hassle (just my time - and yes I'd love it if the boss would spring for some of the commercial auto-update tools).

I can no longer do this in Windows 7. Now I have to log the user off, perform the update, then let them log back in. This increases the amount of time and inconvenience for both of us *dramatically*.

For Windows 7 (and Vista I guess, although I'll never use it), this is what makes the most sense to me:

1. Auto-update enabled, logged on user has required privileges to successfully apply the update - do what you do now - notify the user that an update is available and prompt them to download and install it, when it comes time to perform the install, initiate the UAC prompt (just OK or Cancel and doesn't require a password since the user is already logged on with an admin account).

2. Auto-update enabled, logged on user does *not* have required privileges to successfully apply the update, have 2 prefs to define what happens:

   a) notify the user that an update is available, but they do not
      have the required privileges to install it and that they
      should contact their Administrator

   b) notify the user that an update is available, but they will need
      to provide Admin Credentials with the required privileges to
      apply it, and show an 'Apply Update' button that when clicked,
      prompts for Admin Credentials (if Admin Credentials are not
      provided, there is no attempt to apply the update)

3. Auto-update is *disabled*, logged on user has required privileges to successfully apply the update - do what you do now - do not notify the user that an update is available unless/until they manually check for it, and if/when they do, if one is available, prompt them to download and install it, again inserting the UAC prompt prior to the actual installation.

4. Auto-update is *disabled*, logged on user does *not* have required privileges to successfully apply the update - do not notify the user that an update is available unless/until they manually check for it, and if/when they do (and an update is available), the same 2 prefs would apply:

   a) inform the user that they do not have the required privileges
      to install it and that they should contact their Administrator

   b) inform the user that they will need to provide Admin Credentials
      with the required privileges to apply it, and show an 'Apply Update'
      button that when clicked, prompts for Admin Credentials (if Admin
      Credentials are not provided, there is no attempt to apply the update)

I think OSX could work the same/similar way as Windows, but for Linux, it should depend on how the current app was installed - if it was installed by the distro package manager, then updates should be managed/provided by the package manager, if it was downloaded/installed manually by the user, then I imagine things could work as I described above.

Regardless, this really needs to be fixed so that Firefox and Thunderbird can be updated manually on Windows 7 under a Standard user account with UAC enabled through proper privilege escalation with UAC.

I've also just learned about how to create your own private update service using .mar files, so it would be a huge bonus to also have a pref that allowed you to somehow provide an encrypted form of Admin Credentials to the update service, so that it could silently install updates, but only from your approved source.
Assignee: netzen → nobody

    
    

    
      
  

    
    

    
      
  
Status: REOPENED → NEW

    
    

    
      
  

    
    

    
  
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #145)
> With only bug 529746 (Linux elevation) and bug 529748 (Windows UAC elevation
> for non admin users) I'm closing this bug which became a tracking bug. Since
> it was originally filed for Linux anyone wanting to track the Linux
> implementation should follow bug 529746.
Bah, I got the bug numbers reversed.
bug 529746 (Windows UAC elevation for non admin users) and bug 529748 (Linux elevation).
Since it was originally filed for Linux anyone wanting to track the Linux implementation should follow bug 529748.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: