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.

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

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.

warren, -- Comments From dveditz@netscape.com 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?

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 x.themes.org: "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.

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

*** 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 directory. *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? /be

Bug 51677 is a workaround (or alternate implementation, if you want), not dependency.

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

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

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

warren, please! "we're not fixing that now" is really no reason to close a bug. REOPENing.

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

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

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.

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.

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 script: #!/bin/sh HERE=`pwd` THERE=$HERE/package export LD_LIBRARY_PATH=$THERE export MOZILLA_FIVE_HOME=$THERE (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.

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?

regxpcom also creates $HOME/.mozilla but does nothing with it. It seems superfluous and is not a confidence builder. Bug 57644 filed.

Unsetting target milestone - M18 is long past. Side note: This bug has a patch posted in the comments. Gerv

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... =:-)

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 bug). 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. Thoughts?

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! Hajo

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

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.

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

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

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 companies. 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 fixed. 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: run-mozilla.sh 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.

*** 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? http://www.mozilla.org/projects/l10n/mlp_distrib.html

Here's the shell script that's run after any component is installed. It contains all the bits that need to be done. [snip] #!/bin/sh 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 fi 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.