9120 - mozilla segfaults when run in a non-writable directory

Status: VERIFIED FIXED

(Core Graveyard :: Tracking, defect, P1)

Description

[renec]

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/ .

Comment 1

[chris hofmann]

I think selmer is working on add this feature, or finding
all the areas that will need to change to make it work.

Comment 2

[selmer (gone)]

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.

Comment 3

[leger]

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."

Comment 4

[Suresh Duddi (gone)]

*** Bug 8549 has been marked as a duplicate of this bug. ***

Comment 5

[Suresh Duddi (gone)]

*** Bug 15951 has been marked as a duplicate of this bug. ***

Comment 6

[Suresh Duddi (gone)]

*** Bug 17123 has been marked as a duplicate of this bug. ***

Comment 7

[Suresh Duddi (gone)]

scott, these are all yours.

Comment 8

[Scott Collins]

Added <[e-mail]> at his request.

Comment 9

[Scott Collins]

After investigation with <[e-mail]> 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

  - <[e-mail]> 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.

<[e-mail]> 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?

Comment 10

[Scott Collins]

Note: bug #20777 seems to cover the no-registry case exactly; so we don't even
need to file a new bug.

Comment 11

[Paul MacQuiddy]

renec, does this look good to you now?

Comment 12

[renec]

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...

Comment 13

[Daniel Veditz [:dveditz]]

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.

Comment 14

[Paul MacQuiddy]

finally verified 3/6