Add individual general write access checks for common install write actions

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
10 years ago
5 years ago

People

(Reporter: rumbata, Unassigned)

Tracking

3.0 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

The installer does not create Desktop and StartMenu shortcuts if it is run with unprivileged user and Custom setup is selected (tested with FF 2.0.0.16, 3.0 and 3.0.1). This does not affect Standard setup.The QuickLaunch shortcut is always created. Additionally no "Add/Remove Programs" entry is created if the user does not have admin privileges and regardelss of the setup type.

Reproducible: Always

Steps to Reproduce:
1. Login with a standard user account.
2. Run FF installer for any of the mentioned versions.
3. Choose Custom setup.
4. Finish the installation.
5. Try to un-install FF.
Actual Results:  
The browser is successfully installed, but no shortcuts are created on the desktop or in the start menu. If the QuickLaunch icon was selected at install time it is the only way to start FF without browsing the file system. Normal un-installation is not possible

Expected Results:  
The shortcuts selected during installation should be created in the user's profile. An entry should appear in "Add/Remove Programs" to allow the user to safely un-install FF (this is possible - install any game from www.alawar.com as a normal user; go to "Add/Remove Programs" and you will see an entry and it can be run by the same user or by an administrator; I consider this VERY user-friendly).
(Reporter)

Updated

10 years ago
Blocks: 446619
I just ran the installer as a standard user, chose a custom setup, and the shortcuts were created in the user's profile.

Adding qawanted to see if someone else can reproduce.

The Add / Remove Programs issue is a separate issue and I'll look into what can be done as time permits.
Keywords: qawanted
(Reporter)

Comment 2

10 years ago
I have tried it at least twice yesterday - once on a real PC and once on a virtual. It was behaving exactly as described.

Can I help somehow with additional testing?
You could attach the install.log located in the installation directory
(Reporter)

Comment 4

10 years ago
(In reply to comment #3)
> You could attach the install.log located in the installation directory
> 

Now you got me! I tried to reproduce it and I was not able. Of course the conditions are not exactly the same, so I will leave the bug like this for now. Next week I will be able to test under the same conditions as I did when filed the bug. If I am still unable to reproduce it I will close it my self.
(Reporter)

Comment 5

10 years ago
Created attachment 332680 [details]
Firefox Setup 3.0.1.exe installation log
The install log shows that the following shortcuts were created

  Added Start Menu Directory: D:\Rompetrol Documents and Settings\All Users\Start Menu\Programs\Mozilla Firefox
  Added Shortcut: D:\Rompetrol Documents and Settings\All Users\Start Menu\Programs\Mozilla Firefox\Mozilla Firefox.lnk
  Added Shortcut: D:\Rompetrol Documents and Settings\All Users\Start Menu\Programs\Mozilla Firefox\Mozilla Firefox (Safe Mode).lnk
  Added Shortcut: D:\Rompetrol Documents and Settings\All Users\Desktop\Mozilla Firefox.lnk

Did it create them or were you still unable to reproduce per comment #4?
(Reporter)

Comment 7

10 years ago
It seems that this is NOT ALWAYS reproducible, but still it is. In this log it
is visible that the installer claims to have successfully created shortcuts in
the common start menu, it actually did not do that (it was run under a limited
user acount). Unfortunately I did not find anything about the desktop shortcut,
but the checkbox was checked, and no shortcut appeared.

I am not sure if this is relevant, but note that this installation was
performed on a real computer (e.g. not a virtual one) in a RDP session.
(Reporter)

Comment 8

10 years ago
Ooops! Now I see that it has 'created' also the desktop shortcut in AllUsers. It actually did not.
What kind of limited account are you using? It appears to have created several registry keys under HKLM yet it was unable to create them under HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\
(Reporter)

Comment 10

10 years ago
This keeps getting stranger.

I checked what keys existed under HKLM Software and here is what I found:
1. I (as a limited user) am not able to create anything under  HKLM Software.
2. The mentioned keys DID exist and I was the owner - probably they were left over after a test in which I had admin rights.
3. After I deleted the keys, the installation successfully created the requested shortcuts.

I think may be these pre-existing keys somehow prevented the installer from creating icons.

I will make some additional tests to see how it works.
(Reporter)

Comment 11

10 years ago
Here are the new steps to reproduce this bug:

1. Login with an administrative user account.
2. Install FF (new)
3. Uninstall FF (this leaves HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla and HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org)
4. Login with a standard user account that has write access to the registry keys from 3 (e.g you were admin, but then your rights were revoked; the keys were created by you so you are the owner and still have write access to them).
5. Run FF installer for any of the mentioned versions.
6. Choose Custom setup (only necessary if you do not have permissions to create folders under %PROGRAMFILES%).
7. Finish the installation.
8. No icons are created.
(Reporter)

Comment 12

10 years ago
Considering the latest discoveries on this I suggest to close this bug (invalid or worksforme?) and create a new one that will have correct summary and details.

Is this OK?
Just leave this bug open and I'll consider ways to fix this scenario.

There should be a step between Step 3 and Step 4 that would be grant a standard user account write permissions to HKLM\SOFTWARE\Mozilla.
(Reporter)

Comment 14

10 years ago
This intermediate step is only necessary for testing purposes, since it is very unlikely to happen in a real situation. This is how I discovered it: I had temporary granted to my self admin rights to one PC; forgetting this I installed FF for me only (or so I was thinking); after I discovered what I did I removed it as an admin, revoked my rights and then installed it as regular user.
This is still an edgecase but we may want to have additional tests for each area of the filesystem and registry we work with. Something like testing for All Users Desktop with fallback to current user's Desktop, All Users Start Menu with fallback to current user's Start Menu, HKLM\Software\Mozilla with fallback to HKCU\Software\Mozilla (we already have this), HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall etc.
Keywords: qawanted
Summary: Installer skips/fails to create some shortcuts in custom setup if user is unprivileged → Add individual general write access checks for common install write actions

Updated

8 years ago
Version: unspecified → 3.0 Branch
This is so extremely rare that I am going to resolve it as wontfix.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.