Closed Bug 42184 Opened 22 years ago Closed 18 years ago

Mozilla-bin must not write to bin dir during installation


(Core :: XPCOM, defect, P3)






(Reporter: BenB, Assigned: dveditz)



(Keywords: arch, relnote, Whiteboard: [relnote-user] For tarballs, fixed by bug 90879.)

Split-off from bug 41057.

The problem is security. You should not run a beast like Mozilla as root, you
can't be sure that it has no security holes.

I think, the install process (if needed at all) should run as separate binary.
The workaround is to run Mozilla as user and then change access rights. Not
quite a good solution.
So if mozilla can't write to the bin directory during installation, then how 
does it get installed? Your description of the problem you're trying to solve 
is a bit muddled.

What does running as root have to do with it? Mozilla just needs to be run by 
someone with permission to write in those directories.

Anyway I'm passing this bug off to warren for lack of anyone better. It's not 
the install that's doing this writing, it's XPCOM autoreg, chrome registration, 
profile creation and other parts of mozilla.
Assignee: dveditz → warren
Component: Installer: XPInstall Engine → XPCOM
Keywords: arch
> So if mozilla can't write to the bin directory during installation, then how 
> does it get installed?

I was speaking about mozilla-bin, the app suite. Running a small (!)
command-line install tool is fine.

> What does running as root have to do with it? Mozilla just needs to be run by 
> someone with permission to write in those directories.

Yes, this is what I addressed with my comment at 2000-06-11 15:50. Yes, you can
change the access rights of <mozbindir> and all parent folders (at least on
Unix, if I'm right), install Mozilla and then change all of them back. I don't
think, this is a good solution.
Mozilla should distinguish between the destination location and the
installation location. The first is Mozilla's final resting place and
the second is an intermediate directory. For the more trusting they
would be the same; for the more paranoid they would not. For the really
paranoid, a normal user could run Mozilla's installation script,
including any configuration executables, and then root could look over
what was done and change anything she thought was inappropriate,
including permissions and ownership. The really paranoid root never runs
an untrusted program. All she has to do is run system utilities.

Note that the GNU autoconf system allows exactly that. For the typical
source package, one can say:
        ./configure --prefix=/usr
        make install prefix=/tmp/package-foo/usr
and the right thing happens. Obviously, a binary package just does the
last step. RPM .spec files often make use of this feature so Mozilla
could also please binary packagers with no extra effort.
I don't see what the difference is between this and the other bug (bug 41057).
Essentially there are two stages
install time
run time

I think bug 41057 is run time
this is install time

Admins want both types to not require root.  But they are separate stages 
possibly [likely] to use different applications.
I'm sorry, but why can't you write to bin during install time? When else are you 
going to write this data?
Target Milestone: --- → M18
They are different in that you must *never* write to bin dir at run time. You
can (and propably have to) write to it during installation, but it must not be
mozilla-bin, the app suite. Running a small (!) command-line install tool is
fine. It should be minimal, so that it is easy to make a security audit (i.e.
check, if there are any possible explaits), as it is often run by root. Some
(see timeless' comments) prefer to not even run that app as root.
Yes, and isn't that covered by the other bug? I think this bug is invalid.
-- Comments From 2000-06-11 09:43 in bug 41057 --
> We need to split this into two cases, the install case and a regular run.
> Mozilla cannot be just unpacked into a directory, it must be run once as part
> of the installation process by a person with installation rights in those
> directories.

This bug is about creating a small programm, which does all necessary writes to
the bin dir in order to allow mozilla-bin to run. The other bug is about
removing all writes of mozilla-bin to the bin dir. Yes, there is propably some
intersection. But you don't want hyatt (who you assigned the other bug to) to
write command line install tools, do you?
Keywords: nsbeta3
Blocks: 41057
No longer blocks: 41057
Whiteboard: [nsbeta3+]
Seems like there is some progress: there are regxpcom, regchrome and regExport.
But we need a user-friendly, non-GUI way to run them. And we need to make sure,
that's all.
Looking at recent builds, if you unpack and chown mozilla as root without first
running it to "install" the application then mail/news and themes do NOT work.
This should be a relnote for M17.
If you want a non-gui way of creating all the necessary files you can currently 
run "mozilla -CreateProfile" which will do all the necessary registrations, 
create a default profile and exit.
Comment seen on

"re Netscape Install
I tried to installed per the instructions, but what they dont tell you: I could
not install it as root and run it as a user. I had to install it into my user
directory and then it would work."

We need to better document this.
Keywords: relnote, relnote2
*** Bug 45229 has been marked as a duplicate of this bug. ***
dveditz: (sorry to reply so late after your comment - I just found this bug)

As Ben Bucksh says in the 8th comment on this bug, it is okay to write to the
bin directory at install time, but it is *not* okay to require that mozilla
itself be run. Even just with the CreateProfile flag. Mozilla is *way* too big
to audit for security.

From a later comment by Ben, it looks like this issue might be addressed by
simply running regxpcom, regchrome and regExport from a shell script as part of
the unix installation (does the tarball have an install script? I use the debian
packages...) If the tarball doesn't have an install script, having a
README.packaging file that documents that it is necessary to run these three
programs in the "postinst" part of your packaging script would be good.

If these three scripts really do do *all* the processing that ever needs to be
done as root, then creating a README.packaging file or modifying the install
script would probably be all that was necessary to mark this bug FIXED. Right?
*** Bug 48235 has been marked as a duplicate of this bug. ***
*** Bug 50528 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
*** Bug 43091 has been marked as a duplicate of this bug. ***
I just tried to re-open 43091 but this is just as good. I can't even
run moz as a user anymore - segfault. Could someone answer this
question - doesn't Moz have to write into the component registry during
normal operation? Like, I change the skin or something? If so, then
I should have my own, user-owned copy of the registry, right?
Doug -- you should try to reopen that bug or some other child of bug 41057 
which deals with Mozilla at run-time. You should NOT need access at run time in 
general, your private selections are written to files in your profile 

*this* bug deals with the fact that Mozilla requires write permissions the 
first time in order to do the initial registrations. 41057 is a simple bug 
(ok, lots of bugs), this one is a tougher architectural problem since we 
assumed an "install" step.
Ok, *MY* copy of Mozilla is definitely writing into the install directory.
Here's what I did today:

-Downloaded the Daily Dump.
-Untarred xzpf.
-Ran mozilla as user: Segfault.
-Against my better judgement, ran mozilla as root: no problem.
-Ran as user again: Segfault.
-Back to root and "chmod -R a+w ."
-Back to user and run mozilla: no problem.

To me this is a watertight case that it is writing in the install
directory.  I'll go and post this again on bug 43091 to try to
focus some attention on this SEVERE PROBLEM.
Warren's away this week, can we get someone who is around to fix this?  It is
indeed a bad thing for a Unix app to try to write to system directories.  Dan,
can you help?

Depends on: 51677
Bug 51677 is a workaround (or alternate implementation, if you want), not
No longer depends on: 51677
*** Bug 53693 has been marked as a duplicate of this bug. ***
*** Bug 53918 has been marked as a duplicate of this bug. ***
Not holding PR3 for this; marking nsbeta3-.
Whiteboard: [nsbeta3+] → [nsbeta3-]
Keywords: rtm
Keywords: relnote3
*** Bug 53639 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0
Bug 55419 would regress this bug.
How can you regress a bug that isn't fixed?
Making it worse than it was before. Like ill (a cold) -> more ill (cancer).
At this point, I really don't see the difference between this bug and bug 41057.

There is a complaint that you shouldn't run mozilla at install time because it's 
too big to do a security audit on, but we're not fixing that now. 

Marking dup.

*** This bug has been marked as a duplicate of 41057 ***
Closed: 22 years ago
Resolution: --- → DUPLICATE
warren, please! "we're not fixing that now" is really no reason to close a bug.
Resolution: DUPLICATE → ---
warren: yes, that's *exactly* why this bug was split off from bug 41057 -- 
because we knew that one needed fixing NOW and this one needs some thinking and 
I don't know who nominated it for rtm though -- no way we'll get this 
rearchitected in that time frame. Giving [rtm-]

relnoteRTM text: (something like) On systems where Mozilla (Netscape 6) is 
installed into a directory protected from writing by users, it must be run 
the first time by a privileged account to write out necessary system 
information files. This task is normally performed automatically by the 
Keywords: relnoteRTM
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]
Then perhaps you should rename this "mozilla shouldn't be run during install". 
I really don't know why that's interesting though.

As I said in bug 41057, there's only one remaining problem, and Hyatt thinks 
there's an easy fix. But I'll let you be the judge, Dan. 
Assignee: warren → dveditz
The summary warren suggested would be OK with me.

warren, apps running as root should undergo a detailed security review. Doing
that with mozilla-bin is practically impossible. E.g., IIRC, the GTK developers
recommend not to run GTK as root.
I believe it's relatively easy to eliminate the need for running Mozilla
at install time.

If I run regxpcom and then regchrome the only thing running Mozilla does
is to create package/chrome/user-*.rdf files.

With a 1012 build, if userA has no ~/.mozilla, unpacks a tarball, and
runs Mozilla from there then package/chrome/user* files are created. Any
other user can then run mozilla quite happily. If userA switches themes,
say, then she acquires a local user-skins.rdf file. Now let's say she
want to install a newer tarball so she removes the old one and repeats
her steps. Mozilla now notices that she has a local user-skins.rdf file
and does *not* create a global one. All other users are now screwed
because Mozilla can read neither a global file nor a local file but is
trying to write a global file which fails. Mozilla hangs and just sits
there looking stupid.

Since Mozilla appears to be happy with just local user-* files, and they
appear to really be per-user files, then I think Mozilla should write
these files to the local location always.

If you do that then everything falls into place. A non-privileged user
can unpack a tarball and then run regxpcom and regchrome. A privileged
user can then come along and change the ownership and permissions as
desired and move the directory tree to its final home or even create a
functional binary tarball. What's nice is that this could easily be a
shell script. Best of all, the privileged user never has to run
untrusted applications.

There are some minor problems. Regxpcom is currently linked to the GTK
and X11 libs. This appears to be unnecessary and is probably just a
build bug. A somewhat bigger problem is that behaves poorly when it
can't write to a file but that's not this bug.
regchrome should cause the user-*.rdf files to be written as well.  If not, then
the installed-chrome.txt is probably misordered such that a select command is
happening prior to the install command of a package that the select command
wants to operate on.  Move the select commands to the very bottom of
installed-chrome.txt and then run regchrome, and you shouldn't even see any
user-*.rdf files generated.
Depends on: 56634
What does a select line look like? All lines in installed-chrome.txt are of
the form *,install,* .
*** Bug 56444 has been marked as a duplicate of this bug. ***
*** Bug 56616 has been marked as a duplicate of this bug. ***
Once the user-*.rdf problem is solved, it becomes (almost) trivial to write a
command-line install script although something like ./configure; make install
would probably be more useful.
Here's something to try. As userA unpack a mozilla nightly. Then run this



(cd $THERE; ./regxpcom)
(cd $THERE; ./regchrome)
touch $THERE/chrome/user-skins.rdf
touch $THERE/chrome/user-locales.rdf

Do not run mozilla as userA. Instead try it as userB. It works for me with
empty user-*.rdf files.
Keywords: patch, review
Is there a commandline xpi package installer in the works?
Ben: please elaborate -- isn't that what the Linux installer already is? It 
downloads and installs .xpi files. Are you just asking for an admin-friendly 
"silent" mode?
dveditz, the Linux installer is an X11 app, not?
Depends on: 57089
regxpcom also creates $HOME/.mozilla but does nothing with it. It seems
superfluous and is not a confidence builder. Bug 57644 filed.
Keywords: relnote2, relnote3
Whiteboard: [nsbeta3-][rtm-] → [nsbeta3-][rtm-] relnote-user
Unsetting target milestone - M18 is long past. Side note: This bug has a patch 
posted in the comments.

Target Milestone: M18 → ---
Uhm, X11 installer is a _bad_ idea on Unix/Linux - some multiuser systems on big
sites are running headless as servers and share their dirs with their client
machines. An unix installer should have an option to run without X11 during
installation (does someone remember these =x)(&//!! Oracle installer which can't
run without X11 but does not use it... =:-)
Keywords: mozilla0.9.1
FYI: I tried to use regchrome and regxpcom (as the owning user) only, but
Mozilla coredumped (when run as a different user). After I ran mozilla-bin (as
the owning user), everything worked fine (also when run as a different user).
I didn't track down the reason.
Filed bug 77365 to request a command-line xpinstall binary (as discussed in this

I wonder if this bug should be marked fixed? Most people seem to be having
success with regxpcom+regchrome+touching those two skin files. Ben, did you try
the full script suggested by tenthumbs above?

One other question: Could we possibly run regxpcom and regchrome and create the
skin files as part of "make install"? That would stop people who just run
./configure && make from running into this and complaining because they didn't
read the docs.

if that script works, why don't we include the script also in .tar.gz binary
packages, so that after unpacking, you only have to run the script and are able
to run the program?
I think this is also what an rpm installation (of some distributor) would need
and would be able to do, right?

Note Ben's comments about having problems running only regchrome and regxpcom -
what about that? Does it mean the script will also fail? What can be done
against that?
*** Bug 78487 has been marked as a duplicate of this bug. ***
That you need to run mozilla once with write permission to MOZILLA_FIVE_HOME,
before Mozilla is installed, is one thing. But it's really annoying, that if you
don't know about that (and I couldn't find that in the release notes), you won't
easily find out, because neither regxpcom nor regchrome will tell you. They just
exit without printing something like "no write permission to MOZILLA_FIVE_HOME".
I 've just installed mozilla0.9 on a LinuxBox for multi-user-access.
Postinstall I did a ./mozilla as root but when I did start mozilla as normal
user I got a SegFault!!!
An "strace $prog ${1+"$@"} " in run-mozilla told me, an "open(...
/mozilla/chrome/user-skins.rdf ...) " failed!
During running mozilla first time as root this file wasn't created!
After cp an old one from mozilla0.8.1 into "/mozilla/chrome/" everything is
fine, and I can run mozilla as normal user!
I hope this is the right place to post this error!
> During running mozilla first time as root this file wasn't created!

I think I can answer this one. The RDF files such as user-skins will NOT be
created in the install tree if they already exist in the user's profile tree.
If you're running Mozilla from root with the intention of having it create the
RDF files in the install tree, then root must have a clean profile tree.
It seems awfully silly to impose a restriction that the installer
process not have a ~/.mozilla tree.

In any event, touching $MOZILLA_FIVE_HOME/chrome/user-skins.rdf has
always worked for me. The only thing left in this bug is why Mozilla is
why mozilla fails so miserably if the global user-*.rdf files don't
You can have a ~/.mozilla tree, you just can't have the RDF files in it.

I'm not saying this is desired or even acceptable, I'm just saying that's the
I've observed it working.
Depends on: 79520
Why shoudn't regchrome create the user-*.rdf files? They are for chrome.

Also filed bug 79520.
*** Bug 78742 has been marked as a duplicate of this bug. ***
*** Bug 80205 has been marked as a duplicate of this bug. ***
*** Bug 79520 has been marked as a duplicate of this bug. ***
This problem resulted in my inability to run Mozilla after upgrading to 0.9.1
from 0.9.  An entry in the README or installation instructions along with a
descriptive error message when the RDF files are not found or can not be created
would be greatly appreciated.  Simply crashing when this is the case is highly
*** Bug 83282 has been marked as a duplicate of this bug. ***
See bug 90879. It describes a way to generate a tarball, which can just be
extracted to a dir by root and be used by users. root never has to run any
Mozilla binary.
Whiteboard: [nsbeta3-][rtm-] relnote-user → [relnote-user] For tarballs, fixed by bug 90879.
This one should be nominated as a MUSTFIX for
Mozilla 1.0 (I see no entry for the target milestone)!
Up to now three system administrators of larger institutes 
(> 100 employees) said to me they will not install Mozilla 
if it must be installed for every user (will take up too much 
space and too much worktime). So this one gets to be a major 
blocker for Mozilla's success on multiuser systems in larger
We here (124 employees) are anxious to install even the 
beta releases, as they are more stable now than Nav 4.x on 
Solaris, but we probably must wait forever if this is not
By the way, that one is a really ugly design error, such
bad things shouldn't happen in the future !
FWIW, I've been able to do a shared installation for several thousand users
on both Solaris and Linux.  The trick is to install it in the shared system
directory, then run it once as the owner (i.e. the user with write access).
After that all the other users can run it read-only.   Kind of messy, and 
perhaps there are undiscovered problems with this approach, but so far it
seems to work OK for us.
I agree, this is a MUSTFIX for 1.0.

I, also, have had no problems with this procedure:
as root: untar everything to /usr/local/mozilla
as root: chown -R me.users /usr/local/mozilla
as me: and exit
as root: chown -R root.root /usr/local/mozilla
thereafter, it runs fine for everyone.

The workaround is so simple, I can't believe it's that hard to just make it 
work like it should.
Depends on: 92898
*** Bug 94584 has been marked as a duplicate of this bug. ***
*** Bug 94771 has been marked as a duplicate of this bug. ***
*** Bug 99887 has been marked as a duplicate of this bug. ***
This bug requires a release notes entry. Can someone provide a one or two
explanation of the problem along with any worksaround? 
"Correct Mozilla installation requires initialization of component and chrome
registries.  If installing on a multi-user system, the initialization must be
performed by a user (such as "root" on Unix systems) with sufficient privileges
to create and modify files in the Mozilla installation area."

Blizzard, can you provide a quick bulleted list of the steps required to
initialize the databases?  I'll love you forever.
I had written the doc how to add language pack to
Mozilla that is installed in shared directory on
UNIX platform. Does this help?
Here's the shell script that's run after any component is installed.  It
contains all the bits that need to be done.



umask 022

if [ -f /usr/lib/mozilla/regxpcom ]; then

    /bin/rm -rf /usr/lib/mozilla/chrome/overlayinfo
    /bin/rm -f /usr/lib/mozilla/chrome/*.rdf
    /bin/mkdir -p /usr/lib/mozilla/chrome/overlayinfo
    /bin/rm -f /usr/lib/mozilla/component.reg

    MOZILLA_FIVE_HOME=/usr/lib/mozilla \
        /usr/lib/mozilla/regxpcom >/dev/null 2>/dev/null

    MOZILLA_FIVE_HOME=/usr/lib/mozilla \
        /usr/lib/mozilla/regchrome >/dev/null 2>/dev/null

exit 0
*** Bug 79520 has been marked as a duplicate of this bug. ***
how is this any different than bug 57089?
Bug #57089 is installer only, this one applies to tarball only installation as 
well. Note that #57089 is in the dependence list of this bug, so it fixes parts
of this problem.
(In reply to comment #79)
> Bug #57089 is installer only, this one applies to tarball only installation as 

no one is forcing anyone to run Mozilla to write to the installation dir after a
tarball installation.
Indeed. But if you don't run the script shown in comment #76 (and mentioned
explicitly in the release notes), you run exactly into the same problems
as in bug #57089. So you ARE forced to run it if it should work for anyone 
else than yourself (aka 'root' in a multi-user installation).
you really just need to run regxpcom and regchrome.  The stuff deleted in
comment 76 does not exist on installation, and the directory is made
automagically.  Moreover, what is it preventing you from running the script?  I
don't understand what changes need to be implemented in the Mozilla source to
fix this bug.

I think the summary here is not helping me.
> Mozilla-bin must not write to bin dir during installation

1. No one forces you to run mozilla during tarball installation.
2. If you do run mozilla and you haven't run regxpcom/regchrome, it *must* write
to the installation dir, or it will crash and burn.
All what is left in this bug is that the script is not automagically
fired up in a tarball installation. Yes, it must write to the bin directory
(if calling Mozilla or the script here is irrelevant, one of them must be
run to get the desired effect). I think that the alternative (that is, rewriting
Mozilla so that it does not need the scripts) is not worth discussing any longer,
since the script solution is adequate. From my point of view, this bug is of no
practical relevance anymore, so it may should be closed now.
Hmmmm... maybe it should be said another way.

The fact that the release notes even has a section named "Multi-User Linux
Installations" is a bug.  It is a work-around for a broken install.  Multi-user
is the norm on Unix and Linux.  I might find it understandable to see special
instruction for single-user installs but even that would be unusual.

The install instructions should NOT tell the installer to "Run Mozilla with the
./mozilla run script".  The installer is often root and this is a security
concern for most system administrators.

A posible fix is to elliminate the "Multi-User Linux Installations" work-arround
 section and the "Run Mozilla with the ./mozilla run script" step.  Package the
script mentioned in the "Multi-User Linux Installations" that runs regxpcom and
regchrome, perhaps in a "smarter" form if necessary, and include it in the
installation.  Maybe call it "mozsetup" or something.  Then add a step to the
directions telling the installer to run this setup script.
bug 57089 is now fixed, so I don't know what issues remain here.

David: if you think the website docs/README need updating, please file a new bug.
Closed: 22 years ago18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.