Closed Bug 9120 Opened 25 years ago Closed 25 years ago

mozilla segfaults when run in a non-writable directory

Categories

(Core Graveyard :: Tracking, defect, P1)

x86
Linux

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: renec, Assigned: scc-obsolete)

References

Details

Mozilla will not run unless you run it in a directory you have write permissions to, instead of doing something intelligent like writing its preferences in your ~home directory. I imagine this stops -most- people from getting it to run, I only managed to figure out what the hell was going on by getting **** off after 30 mins and running it as root, then wondering why it worked in that case. It shoudl probably open all files it needs to in ~/.mozilla/ .
Assignee: chofmann → selmer
I think selmer is working on add this feature, or finding all the areas that will need to change to make it work.
Assignee: selmer → dp
This problem is probably related to the creation of the component registry or the profile registry global files. We need a place to store application global data and it must be writable. For the component registry, this should only be required on the first execution of the app. For the profile registry, you would need to be root every time you create a profile (until we make the profile registry live in the user's home directory.) I think dp already has a bug like this, but I'm forwarding it to him in case he doesn't.
Status: NEW → ASSIGNED
Target Milestone: M11
QA Contact: leger → paulmac
Updating QA Contact. Per an email from renec: "Why would you want the program to change ANYTHING global upon a user/new user running the program? (see 'profile'). Profiles are sort of handled automatically by home directories/seperate logins. Its bad policy to alter anything out of a users home directory for any reason.. Stuff everything in ~/.mozilla/, and all the problems go away."
*** Bug 8549 has been marked as a duplicate of this bug. ***
Target Milestone: M11 → M12
*** Bug 15951 has been marked as a duplicate of this bug. ***
*** Bug 17123 has been marked as a duplicate of this bug. ***
Priority: P3 → P1
Target Milestone: M12 → M14
scott, these are all yours.
Assignee: dp → scc
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Added <dveditz@netscape.com> at his request.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
After investigation with <dveditz@netscape.com> this is what we know: - It's OK to run out of a read-only directory (on every platform) as long as your component registry already exists - It is currently the case that if the directory is read-only, and the component registry does not exist, we can't run - We expect in situations where Mozilla has been installed in a context that some users will find to be read-only, that a pre-fab component registry will have been installed as well - <dveditz@netscape.com> says that he may have a reasonable fix the read-only directory + no registry problem, some time in the near future --- if we consider that to be an important case. ...essentially building the registry in memory, but failing to write it out. This would return us to the `slow startup' problem that pre-generated registries were to dig us out of. <dveditz@netscape.com> says that _this_ bug is essentially fixed; and I should close it. If we require another bug for the no-registry case, one can be created. Dan, is this an accurate summary?
Note: bug #20777 seems to cover the no-registry case exactly; so we don't even need to file a new bug.
renec, does this look good to you now?
I'm confused as to why a 'component registry' has to be dynamically generated/saved just to run the program and why it isn't part of an install process if its something that has to be created by root, and kept in a non-writable directory. Most of my confusion is that I don't know what a component registry is - if its something particular to a specific instance of the program, it should be in the user's home directory, if not it should be part of the install process and not touched after that...? Thats about all I have to say about that. Mozilla should probably specifically avoid writing in any directory that isn't ~/ or below, even if it does have write permissions to do so...
The component registry will be installed in the future, but for developer convenience (a component could have been rebuilt at any time) is being checked and potentially updated each run. I have fixes in my tree that turn off this "auto-reg" feature, people will have to rely on the install process or explicitly run the registration utility (regxpcom) with appropriate permission.
finally verified 3/6
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.