287246 - User with "Read only" privileges cant start Firefox

Status: VERIFIED DUPLICATE of bug 286421

(Firefox :: General, defect)

Description

[[e-mail]]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050322 Firefox/1.0+ (PowerBook)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050322 Firefox/1.0+ (PowerBook)

Regular users, which have "Read only" privileges to firefox.app, are unable to
start Firefox.
But it works if you give them "Read & Write" privileges the first time. You can
even set it back to "Read only" afterwards.

It seems like Firefox need write access to firefox.app on the first start.

Reproducible: Always

Steps to Reproduce:
1. Install Firefox
2. Log in as a Regular user
3. Try to start Firefox

Actual Results:  
Firefox dont start

Expected Results:  
Firefox is starting

Comment 1

[Arthur Wiebe]

Firefox needs write access to ~/Library/Application Support and the normal user
should suffice.

Comment 2

[Ben Fowler]

(Not disagreeing with Comment 1 ).

Reporter could you enlarge on the recipe a little. 'Installation' of the Firefox
just means dragging its icon to either /Applications/ or ~/Applications/ .

I don't see why you performed step 2.

(Do you have the root user enabled?).

If you had somehow managed to create directories that Firefox later needs to 
write to as the root or admin user, then I can see that there might be 
problems ...

When you speak of Read only and Read/Write privileges are you referring to
using 'Get Info' on the installed app ?

It is possible that you are doing something that an end-user would not feel 
the need to do.

There is a Mac OS X FAQ sheet at 
http://forums.mozillazine.org/viewtopic.php?t=131693 
(Referenced from http://forums.mozillazine.org/viewtopic.php?t=106431 )

Comment 3

[Ben Fowler]

See also Bug 254234 "Mac OSX Installer/Start Up Investigation"

Comment 4

[[e-mail]]

By installing I mean drag and drop firefox.app from the disk image into
/Applications/
When I (an Admin) user install Firefox in /Applications/ its not possible for
regular users to launch it from their account.
Of cource the users could create a ~/Applications/ folder and install Firefox
themselves, but thats not a perfect sollution on a multiuser system (say we have
10 users, each one of them have their own firefox.app)


No root account is enabled.

"When you speak of Read only and Read/Write privileges are you referring to
using 'Get Info' on the installed app ?"
Yes I do. Get info on firefox.app

I may add that Firefox is the only application on my system with this problem.
Even Camino works fine..

Comment 5

[Ben Fowler]

In your comment 0 , you said:
> It seems like Firefox need write access to firefox.app on the first start.

So far as I can tell, this is correct. Are you able to give write access
using 'Get Info' or the terminal to your users? Do your users have the same
problem if you (your being an admin), run the program for the first time.

You may want to check the FAQ and forums (links above).

If your problem is not being frequently encountered, then I fear that you 
are probably doing something to cause it, but I can't say just what at this
stage!

Comment 6

[Ben Fowler]

Are your Users home directories on the boot drive (or are they elsewhere)?

Comment 7

[[e-mail]]

The users have their home directories on the boot drive. A PowerBook G4

I have Admin rights (Read & Write) and can start Firefox from
/Applications/firefox.app, and so can other users if I give them Read & Write
access to firefox.app for their first run. After that I can set their rights to
Read-only and they can still launch /Applications/firefox.app

I really can't see I'm doing something "unnormal" here. I am just installing
firefox as a system wide application for all users, which they are unable to use
with their default user rights!

It cant be right that Firefox requires write access to firefox.app on the first
run, while none of my 40+ other applications (including Camino) need so. ;)

Comment 8

[[e-mail]]

Ben, do this mean that you are unable to reproduce the following?

1. As an Admin user install firefox in /Applications/
2. Create a Regular user with "Limitations > Some Limits"
3. Log in as this user
4. Launch /Applications/firefox.app

Comment 9

[Ben Fowler]

Per my comment 5, I think that your comment 7 is correct, but you quite properly
imply, I don't really know.

I compile my own lizards (I am behind right now because my build tree is 
being used by Thunderbird until I can work out why the "security" icon in the
compose window is coming out funny) and haven't actually installed one since
the 9th November last year.

You could take your query to one of the forums - I appreciate that there are
not many Mac OS folk there - and I expect that you will get a better and 
quicker answer there than here. If you do find a clear resolution to the 
problem, please consider submitting an appropriate enhancement to the 
documentation or packaging for Mac OS X.

You could try "installing" as a normal user. I don't quite see why it is that
the group permissions within the Firefox bundle do not allow normal users
to run it when installed as you are doing, but there we are.

You could convert this bug report into a request that (at least on the Mac)
Firefox does not write to itself. This might solve the issue that Firefox
does not run from a (locked) disk image.

Comment 10

[[e-mail]]

Thanks.
I will see what I find out and come back when I have more information.

Comment 11

[Hanspeter Niederstrasser]

As a note, on Linux FF needs to register some files into the application dir. 
This is normally done either on first run or during the installation step. 
Because the app dir is usually owned by root, either step must first be done by
a user with elevated privileges.  Afterwards, normal users have no problems
running the app.  This sounds like the same issue.

This is also a dupe of Bug 286421.

Comment 12

[[e-mail]]

Hanspeter.
Thats exactly the same problem, so I'll mark this as a duplicate of <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=286421">Bug 286421</a>

Thanks! 

*** This bug has been marked as a duplicate of 286421 ***