Overview Description: Mozilla writes several files into the binary directory upon startup. On most multi-user OSes, users don't have write permission to the binary files. Not only that but mozilla will CRASH about 50% of the time on startup if it can't write to that directory. Steps to Reproduce: 1) Download and unpack the latest mozilla nightly. 2) Make the directory writeable only by the super-user. 3) Try to use mozilla as a normal-user. 4) Then make the directory world writeable by anyone. 5) Try to use mozilla as a normal-user. Actual Results: About 50% of the time mozilla will SEG FAULT on startup with the following in the debug window when it can't write to the binary directory. WEBSHELL+ = 1 WEBSHELL+ = 2 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file: ///home/david/.mozilla/default/chrome/user.css' failed. Error code: 16389 Segmentation fault. If the binary directory is world-writable then mozilla works fine. It add/removes/changes some files in the binary directory (see below). Expected Results: Mozilla should start nomally and not try to create files in the binary directory. This a big security risk to require that binaries be writeable by anyone. If this can't be fixed by M16, this should at least be in the release notes. Reproducibility: everytime Build Date & Platform Bug Found: 2000053008 i686 linux Additional Builds and Platforms Tested On: none Additional Information: If mozilla has write permission to the binary directory it will create/edit/remove the following files. Add: package/chrome/all-locales.rdf Add: package/chrome/all-packages.rdf Add: package/chrome/all-skins.rdf Add: package/chrome/overlayinfo Add: package/chrome/user-locales.rdf Add: package/chrome/user-skins.rdf Delete: package/chrome/installed-chrome.txt Modify: package/component.reg

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

Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

reassigning to build config per doron's suggestion

There are two other bugs that deal with the specific files not being writeable by not the problem in general. Setting deps & nominating for nsbeta2 status.

Whem I filed bug 16600, only the first start failed. If Mozilla once ran withwrite access to its bin dir, it ran fine without it after that IIRC. This might have changed with the rdf files. Files a new bug 42148 specific for the rdf files to more easily track work. The COMPONENT is wrong, right? Background: IMO, it is generally a design fault to write to the app dir. Under unix, the file system layout (/usr, /etc and /home) was defined the way it is exactly to remove those writes and so to make e.g. app protection or network sharing possible.

More background for PDT: The whole Unix security bases on the fact that users have no write access to apps. So, if e.g. a JS sec hole is discovered which lets webscripts write to the local filesystem, it should only harm the user who visited that page, *not* the whole system. If users have write access to |<mozbin>/chrome|, the script can place a script there and it would have full access rights *for all users* who start the Mozilla instance. Not sure about invokation, but I guess there are ways to achieve that (maybe some autodiscovery for JS components, and then overwriting a common progid or so). Why don't we have a security keyword?

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. If that's what this bug is about it'll be closed INVALID. In fact i think this is a duplicate but I'll leave this open until I can find the other bug. It's a legitimate problem if you find that Mozilla needs write access after initial installation. Not just uses it if it can get it, but fails it if can't. CC'ing warren because I suspect problems like this fall under his group's perview, it's definitely not a "Build" problem.

I don't understand why it is necessary for mozilla to be run once by a system administrator before it can be used by regular users. Most applications are just unpacked and ready to go. If it really is necessary for a sys admin to do this, then there should be a command line flag -install that will do this without actually starting the gui part of mozilla. Example: I have 20 linux workstations. I want to install mozilla on them. I would have to go around individually to each workstation and log in as root, download and unpack the tarball, start the X Windows, run mozilla, and then logout. If there was a -install option I could do all of this remotely without the need for a gui.

David, you can start X apps remotely. The problem is security. You should not run such a beast 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.

OK, making this the tracking bug for normal runs by users. Filed bug 42184 about the install binary. Where did the Architecture component go?

There's an 'arch' keyword now instead. But I don't understand why this is an architectural issue. It just seems like a (security) bug.

definitely not a build config issue. punting to installer and reassigning to default component owner.

Not an install issue either. This is a basic architectural issue that should be tracked by warren's team. Some of it is bugs, but the XPCOM need to create component.reg and the xpti.dat files are fundamental parts of the product. The first-time run issues have been moved into a different bug, but people have a good point that they shouldn't have to bring up a GUI to install the product.

Not sure what open issue is here. Can you clarify?

Unix and Win NT systems are generally set up so users cannot write to the directories where programs--including Mozilla--are installed. Mozilla, unfortunately, expects to be able to write into those directories on occassion and then fails when it does. The need to write as an install step is OK, but bug 42184 describes the need for a non-gui automatable way for admins to install.

Putting on [nsbeta2+] radar for beta2 fix.

This is really Hyatt's bug. installed-chrome.txt should go away in favor of "xap" files (which I'll build the infrastructure for). Hyatt needs to find another location for all-packages.rdf, etc. They're really caches of what's in the chrome manifests and the xap file (which can come from read-only locations). Maybe they should go somewhere near the user's cache directory.

The cache can be per-profile, and as far as newly-downloaded skins or apps are concerned, it will be. all-packages.rdf, etc. are quite capable of living in the user's profile dir. The only bug that needs to be fixed for nsbeta2 is the fact that skin-switching is done at the install level and not the profile level. This is not the chrome registry's fault. Ben is using the wrong flag in the chrome registry API, and that's why stuff is being written to the install dir. I do agree that installed-chrome.txt needs to be fixed eventually, but I don't think it's an nsbeta2 issue. We can do it in beta3.

Adding the '+' to [nsbeta2], per leger's comment

I removed the + after her last comment.

Putting on [nsbeta2-] radar. Not critical to beta2.

> We can do it in beta3. OK, nominating for nsbeta3

skin-switching problem is fixed. resolving as fixed per hyatt.

Bug 42148 is about the skin-switching problem. This is a meta.bug now. Some of the particular problems seem *not* to be fixed. REOPENing. I guess, hyatt just doesn't want to own it, so I'll reassign to nobody. If somebody has a better idea, reassign.

/

Note that it seems that you can't run mailnews unless you have write access to the bianry directory.

Wow, Richard, can you figure out, which file is the culprit (the blocking bugs might help you)? Assuming Richard is right, this is pretty severe and IMO needs to be fixed for nsbeta2. Removing [nsbeta2-], so PDT at least sees this.

/usr/local/mozilla/chrome/overlayinfo and its subdirectories is not world-readable or searchable. chmod a+xr seems to fix it. So this part is probably just a packaging problem. Filed bug 46984 against Instakller component for it.

Restoring SUMMARY. "Read-write permission problems on multi-user systems." is not specific enough, see bug 42184. Also, it is misleading, as this bug is also a problem for well-setup practically-single-user systems (which are just technically multi-user systems, like WinNT and Unix).

Restoring the {nsbeta2-] I removed, because bug 43091 has been filed specifically about the Mailnews disappearing problem. Also, removing dependency on some bugs. This bug is *only* about mozilla-bin trying to write to the inst dir during normal runs, not a catch-all about permission problems.

I was wrong in once case. The problem in bug 43091 is actually, that Mozilla tries to write to the chrome dir. Readding the dependancy.

See possibly related bug 42184, Mozilla-bin must not write to bin dir during installation.

Taking this back from nobody@mozilla.org

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.

David, that would be bug 42184.

I can't even run Mozilla as a user anymore and haven't been for several days now. Here's what I did just now: -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. So this means it's dependent again on writing into the install directory. As we all agree, this is a Bad Idea, and "fixing" this SEVERE PROBLEM by changing the file permissions - well, if you are going to do that, then it should only be installed completely in user filespace and there should be a release note to that effect.

I have a cron job that automatically downloads and unarchives the latest nightly Mozilla. It's worked perfectly up until about a week ago. When it was working, there was a file in the /package directory called "component.reg" When it stopped working, it was when that file was left out of the mozilla-i686-pc-linux-gnu.tar.gz file. When I go to start mozilla, it tries to create component.reg, and since I don't have write access to that directory as a regular user, it just dumps me back to the shell prompt. Even running the installer version as root and trying to launch Mozilla as a regular user (which is the standard way of installing / using software on a Unix-like OS) did not work for me! (same problem) I sure don't like it, but there may be some way of justifying the first case, where I can't just unpack and go from the nightly build. It sure breaks any automated way of installing Mozilla! But as for the Installer version failing, this is a BIG problem!

Adding dependency: bug 49507 (nsbeta3, P4): PSM does not work if Mozilla doesn't run as root. CC: ddrinan@netscape.com

In case it helps, I have a script just like wdormann's and it started failing at the same time. I just put Mozilla onto a fresh RedHat 6.2 install and it works properly when run as a user after installing "tar xzpf" and running mail after starting Mozilla as root (yuck). On my Mandrake 7.1 system with Helixcode Gnome it runs if I start it in the install directory but segfaults if I start it elsewhere. This does not happen on the RedHat system, which is very strange. Huh? What does the current working directory have to do with it? This may explain some of the "works for me" responses to this issue.

Adding mostfreq. This propduces completely confusing problems, in which many users run.

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

warren, ping? I know, you're the most doomed, but should you give th bug away then? This continues to be a big problem. I am sick of reading/evaluating dups/dependant bugs of this bug and bug 42184. I gave up to understand this mess. Please someone investigate, make a plan and clean it up.

Because many, many users ("testers") run into this problem, marking DOGFOOD, finally.

My idea was to put these files in the cache directory (or someplace like it specifiable by a pref). I'll try to get it in this weekend. How come Hyatt isn't cc'd on this?

Not holding PR3 for this; marking nsbeta3-.

I don't think this stops dogfood usage, probably just large central deployments. I'm marking dogfood-minus. I can believe this is an rtm bug, and I sure hope we see a small fix RSN.

Another permissions problem is this: If you install Mozilla as root (which I think is expected) and then run it as a normal user (again, quite standard in the Unix world) The word "Composer" does not appear in the preferences. Check out bug 53674

it's a little bit worse than wdorman states: It can seem likt it is not only required to run browser once anymore (to create files/dir's under chrome according to installed components). Seems i have to start each and every installed module once as root as well; mailnews, composer, addressbook. (for instance.) If i don't start at least Composer as root once, bug 53674 and bug 53680 triggers when i run moz as regular user. (missing menuitems for composer in prefs, and missing items in composer's menubar)

not sure, but a slightly worse phenomena MAY be that talkback for installed builds are affected. I've crashed about as often as "usual" the past two days or so, but no talkbacks anymore. (currently 2000-100106)

I'm not quite sure why this is nsbeta3- and not + (or ++) since this essentially prevents to use Mozilla/Netscape 6.0 to run on Unix. (I neither want to have 200 copies of 32MB or want to have allow 300 users to have write access to a shared directory.) This prevents the usage at out computer cluster :-( (And is even on a single unix pc rather irritating not very usefull.)

It's nsbeta3- because that ship has already sailed. If it gets [rtm-] we're dead.

> If it gets [rtm-] we're dead. You don't even need [rtm-]. [rtm+] (not [rtm++]) or the bug lying around for too long will be enough. ;-) I will take some time to clean up this mess. Nice to see you agree on the importance, though :).

> I will take some time s/I/It/ *g*

This also seems to affect the functionality of http-authentification. If I run Mozilla (build id: 2000100308) as a normal user and try to enter a page that has a password (test-example here: <http://www.koldfront.dk/mozilla/password/>) I get the window asking for user name and password, but when I click "Ok" nothing happens (the password-protected page isn't shown). If I run Mozilla as root and try the same, the password-protected page is loaded as intended after correct user name and password entry.

If this and bug 42184 are to go into the release notes, I need a plain-English summary of the problem and what the users can do about it. Also, is really all platforms? And finally, is there any relationship to 49507? Thanks.

Suggested relnote: `If installing Netscape 6 on a multi-user operating system such as Linux, Unix, or Windows 2000, you should install it separately in the user directory of each user who plans to use the program. If you install Netscape in a shared write-protected directory, it may not run properly.' I don't think there's a nicer way of putting it. :-/

Can't you do a chmod -R u+w on the installation directory (or chmods on whatever specific files/directories mozilla is rude enough to stomp on) after installing as root? Not a good situation, I agree, but some sysadmins (especially on systems that only have a few well-known users) might prefer it to installing many separate copies so it might be worth mentioning in the release notes.

Why is this so difficult to fix? There seem to be other parts of the code that know how to fall back to the user directory when the install directory is R/O so there must be some code or interfaces or something to handle the job. Mozilla will also not run on a properly administered NT system for the same reasons, so doesn't that leave Win98 as the only PC OS that a normal installation of Mozilla currently works on?

> Can't you do a chmod -R u+w on the i I guess, the owner (that's |u|, not?) already has sufficient rights. So, this wouldn't help. > especially on systems that only have a few well-known users The problem is not so much the user himself, but what the user does unintentionally. If one user is compromised, all other also are, if you make all files user-writeable. I think, we should not suggest that. Sysadmins wanting to do that will see that it is possible from Matthew's suggested text. Matthew suggested: > "[...] If you install Netscape > in a shared write-protected directory, it may not run properly" I would make that the first sentence, i.e. "If you install Netscape in a shared write-protected directory, it may not run properly. So, if you install Netscape 6 on a multi-user operating system such as Linux, Unix or Windows 2000, you should install it separately in the user directory of each user who plans to use the program." (Note: no comma between "Unix" and "or".)

To add some more info about permissions in UNIXes: Users (application non-owners) running application need only: for app files: execute permissions to app's binaries (read perms. are not necessary!) and read permisions to its configuration files. for app directories: read permissions (not absolutely necessary for some apps), execute permissions. Having to give the non-owners of application write access to aplication's dirs, binaries and global configuration files is _absolutely_ unacceptable! Particular users' config files are to be stored in their home directories (thanks to this, after the application is upgraded (deleted and reinstalled with a new version), all users keep their previous configuration. That's how it works on UNIX systems. That's how it works on Linux.

We're not having trouble understanding the problem or reproducing it here... just trouble getting to the task due to too many other things. Send me a patch instead of more description.

Adding cc

Matthew, thanks for the explanation for the release notes!

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

When I installed PR3 as root, I was not able to run it as cls. After I ran regxpcom & regchrome (regchrome I had to copy from my cvs build), it started up fine. Still waiting to see if there will be other side-effects. Samir, how hard would it be to run regxpcom and regchrome during installation? Or better yet, before those files are packaged? If we know that component.reg & chrome/all-*.rdf need to exist before the browser can run, why aren't we shipping them?

cls, see bug 51677 (Ship pre-generated chrome files if possible).

See also bug 55419 where the installer needs to launch mozilla with the "-installer" flag to take care of these "first time" initializations, performing the regxpcom and regchrome actions as well as 4.x profile migration. Shipping the pregenerated files instead might be OK for Mozilla tarballs but doesn't work well in a component installer with optional pieces. It probably doesn't hurt much to have extra components in component.reg (wastes memory, and the failure to load a component would take an OS call that would normally be avoided) but I think extra registered chrome could be disastrous, especially if dynamic overlays are registered that don't really exist.

I have managed to run NS PR3 as non-privileged user, after installing and running once as root. However, to install any optional component, such as chatzilla or xmlterm, I need to run as root again to get the component installed in the bin/components directory and then registered in component.reg. This means that for a shared install of mozilla, a non-privileged user will only be able to try out browser add-ons that the sys admin chooses to install. This sort of defeats the purpose of XPCOM in a multi-user system. Allowing user-specific chrome does not solve this problem, because this has to do with user-specific component installation and registration, which is an XPCOM issue. (Should this be in a different bug?)

R. Saravanan: local components are covered by bug 14923. We should think about whether that's part of mozilla1.0 or not -- it probably is.

Disclaimer: I know very little about XPCOM, and I'm doing this only because nobody else seems to be doing anything about this bug! I have attached a (trial balloon) patch to xpcom/io/nsDirectoryService.cpp that moves the component.reg directory from the bin directory to the $HOME/.mozilla directory (for Unix platforms only). I'm not proposing that this be checked in, but it may be worth trying out and testing. The patch checks if a file called $HOME/.mozilla/component.reg exists, and if so uses it as the component registry. Otherwise, it uses bin/component.reg. At the moment, you need to create at least a zero-length component.reg file in the user's mozilla directory for this patch to work (this behaviour can easily be changed). With this patch, I managed to install a mozilla tarball as root and then run it as an ordinary user.

svn, cool! This approach sound like the right way, given that users might install components, too. Would be nice, if we could get the patch ready for checkin (and actually do checkin) ASAP.

Hyatt is going to take this. We think there is really only 1 remaining problem here after doing an initial install as root: user-locales.rdf and user-skins.rdf can still be written because of the way the select rules are processed in installed-chrome.txt. He can fix that by deferring the select rule actions until after everything else in installed-chrome.txt is processed.

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

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

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

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

rtm-/future, no time left for this.

> If it gets [rtm-] we're dead. relnoteRTM ...

So we've basically killed the viability of Netscape on Unix? Great. Adding Keyword ns601 to the status bar and hoping that we come out with Netscape 6.01 less then a month after 6.0, before anyone knows that 6.0 exists. This bug has 17 votes for a reason. It should be a "pull it off the wire" bug, because this bug makes it impossible for the sys-admin to install one copy for everyone to use. Simple crashers pale compared to the prospect of a browser that cannot be installed properly for multi-user use IMHO.

Sorry for the spam, but I just though I'd voice my opinion. Yes, vote-wise, this bug is a top-20 bug. This is no coincidence. Mozilla isn't following the *NIX mentality of how software should behave: 1. -Install as root -Run as normal user 2. -Binaries are put in the program directory and never touched again -System-wide configuration goes in /etc -User-specific configuration goes in ~/ (User's home directory) The Linux market is an important target. Right now, Mozilla/NS6 is a Linux user's only hope for a *good* web browser. NS4 is a joke in the Linux world. You want mass acceptance? Alienating Linux users isn't the way to go. Windows / Mac users? Hell, they've already got a "great" browser (IE). Why should they switch? Good luck, folks... </soapbox>

I am currently running Mozilla M18 installed (as root, perhaps obviously) from RPMs. I am not root. Everything works fine. The packager had to be a little bit clever, but it can certainly be done. In light of the fact that Mozilla _can_ be installed such that it doesn't require write access to the installation directory, I think the severity of this bug is overstated. (You don't use RPM? Follow blizzard's spec file to see how he does it, and make Politically Correct packages for your platform: http://people.redhat.com/blizzard/software/ .) There's no way hyatt will ever fix this, or probably even shepherd in a fix, so I'm taking this bug to add to my graveyard. I also disagree that system-wide configuration should always go in /etc, but I don't care enough to argue further: you're more than welcome to tweak and package up something that puts things in /etc, if it really turns you on.

NTLM has more votes than this bug. NetBSD had 2 binary (2) orders of magnitude more votes than either of these. Stop abusing soapboxes. We have newsgroups; please use them. Can a bunch of people test the following: as i_don't_care: wget mozilla.tar.gz | wget mozilla.zip [ftp, http, lynx, netscape, mozilla, I DON'T CARE] as future mozilla owner: tar xzpf mozilla.tar.gz | unzip mozilla.zip [winzip, pkunzip, zipinfo, I DON'T CARE] regxpcom [probably from bin/] regchrome [probably from bin/] as mortal: run mozilla. If you have problems please use: lin: strace sol: truss win: filemon QA people who could do this testing, zach and i have w2k accounts both are willing to be victimized. world: if you don't trust mozilla, find someone willing to let you testdrive it on their system. I filed bug 56429 based on my w2k testing.

> as future mozilla owner: Wrong. Install as root. Users have no write access to /usr. *I* install Mozillas as the user that runs them, and I have no problem whatsoever. But that's not how it should be. Shaver, this bug is certainly not a minor problem. Anybody, if Netscape wants to ship crap - its problem. Let's hope this bug gets fixed soon after N6.

As much as everyone thinks this is evil, since regchrome and regxpcom have been fixed, mozilla itself can be installed as root. The only problem occurs when a user wants to install something besides a chrome pack. IE, sysadmin doesn't have PSM, user installs it, doesn't work because mozilla only looks in global component registry. Replace with aphrodite, or whatever the mozilla appthingy of the week is. While I still think its bull that this ever happened from a design perspective, it has a workaround right now.

I'm sorry that you feel our design to be bovine in nature. There have certainly been alternate designs proposed to permit installation of components in other directories, but this is not a new problem: how does a user install mod_perl for use on their home page? Why hasn't the Apache crowd rushed, klaxons wailing and editors at the ready, to remedy this grievous error? Of course, nobody -- obviously including yourself -- has chosen to implement those alternate designs, and given that there are ways to make this work if you want to, I'm not impressed enough by the urgency to want to devote my personal resources to making it better. I don't think that the mechanisms here are that onerous, but if you disagree you're more than welcome to put your money somewhere _near_ your mouth and come up with ones that are less onerous -- this means ``implement'', not just ``describe fancifully on newsgroups and bug reports''; we have had ample of the latter on this particular issue, including from yours truly. I agree that the ability to install local components would be _nice_ (see 14923, which I started and then graceless dumped on blizzard), but I'm not sufficiently motivated by that particular flavour of ``nice'' to drop the other stuff I'm doing. Maybe someone else is, though -- the source is available. (I don't agree with the concept of moving component.reg to ~/.mozilla/, because it doesn't really improve the situation: you still need to write to the $MOZILLA_FIVE_HOME/components directory to put anything new in place. When you can install components in ~/.mozilla, and have them be found, I'll be more interested.)

And for the record (to the person who claimed you couldn't install Aphrodite), the chrome registry is capable of operating entirely out of the profile directory. That includes newly installed packages. You don't have to run as root to install Aphrodite for yourself (or any other packages you desire). Local components may have problems, but local chrome does not. If you're going to come onto this bug and accuse us of poor design, get your damn facts straight.

Hyatt: I think the problem with aphrodite is that the XPI interface doesn't expose a way to install a component in the profile directory. Maybe dveditz can say more about this issue?

I'm reconciled to having this bug in NS6.0x, but I do think it should be fixed for mozilla 1.0, at the latest. shaver: I agree that moving component.reg to ~/.mozilla doesn't solve the problem, but it is the first step and I would argue a logical one. One has to choose either to have two component registries or a single one. Logistically, it seems it would be better to have just a single one. On multi-user Unix systems, ~/.mozilla seems the natural place to put it. There is a slight inefficiency in that components are registered separately for each user; but that is a much smaller price to pay than the current workaround of installing all the component DLLs for each user that wants to add a local component. This does not solve the problem of autoregistration of local components in ~/.mozilla/components (?), but as a workaround, one can manually install a local component and register it using an absolute file path (I think). (But this discussion actually belongs to 14923, which is the one I'm more worried about, and I'm willing to devote some time to fixing that.) Fixing this particular bug, once component.reg is moved to ~/.mozilla, requires dealing with chrome stuff (per warren's last comment) and it would take me too long to spin up on that. Perhaps I should start a thread on this topic on n.p.m.xpcom?

benb, I said owner because on w2k that is usually administrator and on unix that is usually root. But there is nothing wrong w/ that being a user Wheel that maintains the package suite and does not touch hardware. wrt regchrome: I still don't have it, so you can't call that fixed until it appears in the win32 .zips Leaf: any thoughts?

Shaver: actually, you *can* install profile chrome using XPInstall. To unpack the files you'd want to use getFolder("Profile") to get the currently running profile's directory (or perhaps getFolder("Profile","chrome")), then in the call to registerChrome() you'd want to OR in PROFILE_CHROME as part of the first type argument. So... dest = getFolder("Profile","chrome"); addFile("","myapp.jar",dest,""); registerChrome(PACKAGE | PROFILE_CHROME, dest); assuming myapp.jar has a manifest.rdf at the top level. If you've got contents.rdf scattered throughout you'd have to call the 3-arg form of registerChrome() once for each contents.rdf getFold

svn: moving component.reg to the user profile misses one important point -- if the admin adds a new component all the user component.reg files are now out of date. To make this work we'd have to turn "AutoReg" back on in optimized builds, and we turned it off specifically because of startup time issues. I'd argue we need to add a local component.reg to support local components, but should keep the global component.reg for globally installed components.

regchrome.cpp isn't even apparently built on non-unix systems (which explains the absence in windows builds). Are you sure this is the tool you need?

It is very Unixish to read global and then local config files so I agree that there should always be a global component.reg. I think it would be a mistake to move it to ~/.mozilla. You might be interested in my comment to bug 42184 which makes regchrome necessary but very useful.

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

There's enough Netscape people cc'ed on this bug that I'm just going to put this here. We need to also do something similar for Mozilla so this is relevant to bugzilla. Someone from Netscape please open a bug for this in bugscape. I'm even going to attach this patch to make it clearer. This message needs to be in notes that you see when you install not just in the relnotes. We should change the default install location for the mozilla installer also. diff -u netscape-installer/README netscape-installer.new/README --- netscape-installer/README Fri Sep 29 13:25:33 2000 +++ netscape-installer.new/README Sun Oct 15 18:52:52 2000 @@ -64,6 +64,12 @@ exit all programs before running the setup program. Also, you should temporarily disable virus-detection software. +If installing Netscape 6 on a multi-user operating system such as +Linux, Unix, or Windows 2000, you should install it separately in +the user directory of each user who plans to use the program. If +you install Netscape in a shared write-protected directory, it may +not run properly. + Install into a clean (new) directory. Installing on top of released product builds may cause problems. diff -u netscape-installer/config.ini netscape-installer.new/config.ini --- netscape-installer/config.ini Tue Oct 3 17:50:54 2000 +++ netscape-installer.new/config.ini Sun Oct 15 18:54:08 2000 @@ -1,7 +1,7 @@ ;------------------------------------------------------------------------- [General] ;------------------------------------------------------------------------- -Default Location=/usr/local/netscape +Default Location=$HOME/netscape ; *** LOCALIZE ME BABY *** Title=Netscape Installer

To address David Krause's last comment: I am convinced that there is enough installer behavior difference expected that we should ask the installer user at startup (through the shell script or the GUI) whether the install is intended to be an administrator install or end-user install and present a user experience accordingly. Feature for the next rev.

> Feature for the next rev. David Krause's patch makes a lot of sense to me *right now*.. Currently, the installer defaults to a patch that will not work. What sense does this make? Filed bug 56811.

Assuming that one has worked around bug 42184 then what exactly is broken these days when *running* mozilla from a read-only directory? The only things I see are PSM, component registration, and maybe skin stuff. I can't see how changing the default _installation_ path does anything more than paper over the issue. I also don't see how describing mozilla's inability to deal with OS security issues is going to inspire confidence about the product. But what do I know?

Forgot to add that private copies of mozilla also means private copies of all those shared libraries. Mozilla sometimes grows to >50MB when I read mail. Imagine the fun when three or more users do so.

Temthumbs, please keep the discussion about bug 56811 in that bug.

I don't think David Krause's patch makes sense. We _should_ mention, in the install notes, the need to run regxpcom and regchrome after install (initial and component), but I don't think we should be encouraging people to put Mozilla in their user directories. David, do you want to whip up text about running regxpcom and regchrome (assuming that we get regchrome building on Windows)? I think that would make this bug be a lot less mostfreq. For the next release -- perhaps meaning Mozilla 1.0 -- we might want a command-line xpinstall utility, such that system administrators wouldn't have to run Big Bad Mozilla to install software for their users. (I agree that they should be nervous about running Mozilla as root -- I would be.) If people are interested in such an idea, please file another bug in which to discuss it, and reference it here (perhaps as a dependency).

I've attached a patch for the install docs. It only covers the linux install, until we find out about regchrome on windows. I assume that Mac OSX also has this problem. Comments on the wording, maybe someone would like to make it sound better? Also, I just noticed that it didn't linewrap. If we document this well enough, then I agree my previous patch may not be needed. Just trying to throw out all the possible solutions.

I believe a command line utility is within reach right now.

shaver, this is what bug 42184 is about.

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

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

Running regxpcom and regchrome as root after install (of M18) is not sufficient to avoid the problem when running mozilla as regular user. # diff -r package.orig/ package Only in package/chrome: all-locales.rdf Only in package/chrome: all-packages.rdf Only in package/chrome: all-skins.rdf Only in package/chrome: overlayinfo Binary files package.orig/component.reg and package/component.reg differ some files are still missing: package/chrome/user-locales.rdf package/chrome/user-skins.rdf There may be other problems too, but this is sufficient to prevent a clean install.

Erm no iirc user-*.rdf should land in the user profile directory not in the app chrome directory

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

erm yes. Here's your repro steps... cd /space/src rm -rf package* tar xvfz mozilla-i686-pc-linux-gnu-M18.tar.gz cp -pR package/ package.orig chown -R root:root package export MOZILLA_FIVE_HOME=/space/src/package package/regxpcom ## OUTPUT: RegSelf Shift_JIS to Unicode converter complete RegSelf EUC-JP to Unicode converter complete RegSelf ISO-2022-JP to Unicode converter complete RegSelf Unicode to Shift_JIS converter complete RegSelf Unicode to EUC-JP converter complete RegSelf Unicode to ISO-2022-JP converter complete RegSelf Unicode to jis_0201 converter complete RegSelf Unicode to jis_0208-1983 converter complete RegSelf Unicode to jis_0212-1990 converter complete RegSelf Unicode to Big5 converter complete RegSelf Unicode to x-x-big5 converter complete RegSelf Big5 to Unicode converter complete ## END OUTPUT package/regchrome ## no output ## run as user, doesn't work. output: MOZILLA_FIVE_HOME=/space/src/package LD_LIBRARY_PATH=/space/src/package LIBRARY_PATH=/space/src/package:/space/src/package/components SHLIB_PATH=/space/src/package LIBPATH=/space/src/package ADDON_PATH=/space/src/package MOZ_PROGRAM=/space/src/package/mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= wait ... wait ... wait ... <CTRL+C> ## kill zombie mozilla... ## now as root again: diff -r package package.orig/ ## OUTPUT: Only in package/chrome: all-locales.rdf Only in package/chrome: all-packages.rdf Only in package/chrome: all-skins.rdf Only in package/chrome: overlayinfo Binary files package/component.reg and package.orig/component.reg differ ## END OUTPUT chown -R leary:leary package ## run as user, runs fine ## OUTPUT: MOZILLA_FIVE_HOME=/space/src/package LD_LIBRARY_PATH=/space/src/package LIBRARY_PATH=/space/src/package:/space/src/package/components SHLIB_PATH=/space/src/package LIBPATH=/space/src/package ADDON_PATH=/space/src/package MOZ_PROGRAM=/space/src/package/mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= Setting content window *** Pulling out the charset Loading page specified via openDialog in SetSecurityButton Document about:blank loaded successfully we don't handle eBorderStyle_close yet... please fix me start message pane with: http://www.mozilla.org/mailnews/start.html In SortColumn SetupCommandUpdateHandlers in SetSecurityButton in showthreads In NewEditorWindow()... failed to get command manager number 3 failed to get command manager number 2 Registering commands Have Find = true Have SpellChecker = false we don't handle eBorderStyle_close yet... please fix me failed to set webshell window JavaScript error: chrome://communicator/content/bookmarks/bm-panel.js line 30: window._content has no properties wallet.crypto pref is missing from all.js wallet.enabled pref is missing from all.js imageblocker.enabled pref is missing from all.js we don't handle eBorderStyle_close yet... please fix me In EditorShutdown.. OnUnload from XUL Clean up ... we get here ## END OUTPUT ## now as root again: diff -r package package.orig/ ## OUTPUT: Only in package/chrome: all-locales.rdf Only in package/chrome: all-packages.rdf Only in package/chrome: all-skins.rdf Only in package/chrome: overlayinfo Only in package/chrome: user-locales.rdf Only in package/chrome: user-skins.rdf Binary files package/component.reg and package.orig/component.reg differ ## END OUTPUT <gak!>

Bug 42184 is the appropriate one for installation problems. It has more information about the user-*.rdf issue.

There's been a regression. For a while, Mozilla would write the chrome/user-*.rdf files to the current profile if they didn't exist. With a 110108 build, Mozilla is back to its old ways and tries to write to the global location if and only if the original user had these files when he first ran Mozilla.

Mozilla must write user-rdf files to the install dir for the global and communicator packages only. That's what it's doing right now. It will do it only the first time you run. After that, it will write only to the profile.

I'm confused. With the 1101 build, there are three cases: 1) user A has no $HOME/.mozilla. If user A unpacks and runs Mozilla, then Mozilla creates the global user-*.rdf files and also creates local ones in user A's profile. Other users can run user A's Mozilla whether or not they have a profile of their own. 2) user A has a $HOME/.mozilla from a previous installation. There are user-*.rdf files in the profile. In this case, running a new Mozilla does *not* create the global files. If another user comes along and does not have a profile of his own, then he's screwed when he tries to run Mozilla because his instance tries to write into user A's directory which, of course, fails. If yet another user happens to have a profile, then she *can* run user A's Mozilla. 3) user A is a hacker and runs regxpcom, regchrome, and then creates 0-length global user-*.rdf files. As far as I can tell any user can use this installation without apparent ill effect. About a week ago, Mozilla was not writing global user-*.rdf files under any condition. Maybe that was an error but it had nice side effects.

That's interesting. However, imo case 2 should not be supported behavior. The release notes should say to behave like case 3 if you intend to share your install. Otherwise, we have instructions for single users that say to delete your profile (yes we know that's disliked, there are other bugs on that) before installing/running mozilla.

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

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

Removing myself from cc's... this was release noted.

I want to make sure I'm understanding this properly. PSM is distributed under a restrictive license ("Redistribution Or Rental Not Permitted"). This means that it's impossible for a Linux distributor to make mozilla packages which contain PSM already installed and registered. And, there's no way for individual users to install it into their own directories. So, https won't work until the root user has manually gone through the web-based PSM install process on each machine. In a lab with 100 machines (not using NFS), this would be a fairly time-consuming procedure. Furthermore, doing so goes directly against good Linux practice -- all files in /usr (excepting /usr/local) should be managed by the package manager (RPM, dpkg, whatever). Dumping stuff in the Mozilla bin dir without going through the package system is ugly and breaks things. Am I missing something? I've read through all of the comments on this bug, and realize it's been well hashed-out, but this seems significantly more important than minor/P5.

> PSM is distributed under a > restrictive license ("Redistribution Or Rental Not Permitted") No, PSM is under the MPL. Just the binary version distributed by iPlanet is restrictive, just as Netscape 6 is.

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

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

On Solaris there is a workaround for this available: 1. Create a temp. dir for registry files for each user: % mkdir $HOME/.mozilla/regtmp 2. Soft-link each file in /usr/local/mozilla5 (readonly) which requires r/w permissions to /xfn/thisuser/fs/.mozilla/regtmp/ That should be all... :-) Comments ?

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

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

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

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

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

Adding yet more keywords... shaver, are you still owning this issue in a meaningful sense (just want to know it's in good hands ;-)? Gerv

The only ownership that needs to happen right now it to correct the (lying) release notes. Beyond that, I just sit here and suck up abuse. (Why is this nsdogfood and nscatfood? Are Netscape people not clever enough to either use the installer or run regxpcom/regchrome after install?)

A key problem related to this is the inabilty for normal users to install plugins. (Especially given that when one comes to a page that requires a plugin, it prompts one to get the plugin and install it -- leading to very confused users....) Bug #45699

Shaver- One problem with "use the installer" is that large installations of netscape are very difficult to roll out that way. Doing that on one machine is fine; doing it across several thousand (in a corporate or university environment) is a PITA. It is one of the key reasons why Duke's Office of Information Technology has not yet done a rollout (or so I hear through the grapevine.) So, it isn't a dogfood issue for those of us with one desktop but it is for those with hundreds or thousands.

First off, I don't give a sweet fig about Netscape installations, so if the suggestions here work only for Mozilla, I will not shed a single tear. Now, as has been mentioned _repeatedly_ in this bug, it's quite possible to - install as root - not use the Mozilla installer - have it be runnable by non-root users Chris Blizzard's RPMs do it, the Debian packages do it, I do it with a tarball install, the world is a joyous and sunshiney place. And as if that weren't enough to make this a non-problem for those who actually want to solve the problem, you can actually relocate the installed mozilla directory to another machine -- people, including myself, worked hard to make paths in the registry be related to the install dir, and Duke's IT department is welcome to the fruits of our labour. It might well not be trivial to install Mozilla on 1000 machines, but there's not much about maintaining 1000 machines that _is_ trivial, and I think there exists ample evidence that it's quite possible, and reasonable, to deploy Mozilla ``correctly'' without the graphical installer. Man, is my déja vu meter _pegged_.

Joining into the discussion... Mike. You mention several Linux distributions for which it is possible to run as non-root. But how about Solaris? Yes, there is a Solaris workaround posted in this bug. Unfortunately, on our university Solaris network, xfn is disabled and since I am not a sysadmin I cannot do anything about that except asking the sysadmin to activate it. Since he is already swamped with work and it's not considered an important issue this has not been done yet. Installing in users' home directories isn't feasable because each student has a ~40MB quota limit. See the problem?

What Solaris-specific issue? You don't cite a bug, and I don't know what xfn is, but I don't think there's anything Linux-specific about the techniques employed by the RPM and Debian packages. You could do the same thing in whatever package format you choose for Solaris, or use the oft-mentioned install-and-copy technique. Can you elaborate here (or, better, file a _different_ bug about Solaris-specific things setup bugs) as to why the techniques that work on a pile of Linux distributions don't work for you?

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

Mike, The Solaris workaround I mentioned is from Roland Mainz, posted on 2001-01-16. Perhaps I'm just too inexperienced to figure this out. But although I can run regxpcom and regchrome as a user with write access, as a normal user this means mozilla will hang at startup (no crash, just a freeze after plugin registration). I don't know what techniques are used in Blizzards' RPMs but sure as hell they are not going to work on Solaris. If there is a solution then I obviously missed it and would like a reference to some FAQ where it is mentioned. Thanks.

I've seen this hang before when I was first creating debian packages I figured out that it only hangs if you don't set a default chrome to use I have this in my postinst for mozilla and each of the peices that provides chrome /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 for line in "skin,install,select,classic/1.0" "locale,install,select,en-US"; do if grep -q $line /usr/lib/mozilla/chrome/installed-chrome.txt; then :; else echo $line >> /usr/lib/mozilla/chrome/installed-chrome.txt; fi; done env MOZILLA_FIVE_HOME=/usr/lib/mozilla /usr/bin/regxpcom >/dev/null 2>/dev/null env MOZILLA_FIVE_HOME=/usr/lib/mozilla /usr/bin/regchrome >/dev/null 2>/dev/null

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

shaver: do you know which particular lying (Mozilla) release notes need updating so that you never have to hear about this again? Gerv

Reinout: The Solaris workaround posted by Roland should not be necessary, just as it isn't necessary on any other Unix. I'm not sure what he was thinking, to be honest. How can you be ``sure as hell'' that Blizzard's techniques won't work on Solaris, when you are apparently completely ignorant of those techniques? Unless Solaris differs from Linux with respect to fundamental Unix filesystem semantics, or there is some _extremely_ subtle bug in the XPCOM registration, they should certainly work. If they do not, you should either a) file a bug detailing the specific behaviour that you see on Solaris that leads to this problem, or b) go away. You give next to no information as to what's happening with your build, just that it ``hangs'' after printing some random message to the console. Are you by any chance attempting to use a DEBUG build here, which will always auto-register unless you set an environment variable? If so, I respectfully suggest that you stick to mozilla.org builds. Gerv: Last I checked, the release notes recommended that Mozilla be installed in each person's home directory, and didn't mention the regxpcom or regchrome utilities for setting up the Mozilla installation for non-installing-user use. I'll try and send some corrected text today. All: as I have seen no evidence that a properly-installed Mozilla will actually attempt the heinous sin mentioned in the summary (and I do quite believe that such a thing would be a serious bug), I'm updating the summary to indicate the real issue, which is one of installer education. If you have comments regarding the text that should be in updated release notes, please comment in this bug. If you have comments regarding a perceived failure by Mozilla, on your platform, to avoid autoregistration in a properly-installed setup, please file another bug, against me, with exhausting details of your installation process, and attach a truss/strace/etc. log detailing the attempts to write to the directory. Thank you all for your contributions.

> The Solaris workaround posted by Roland should not be necessary, just as it > isn't necessary on any other Unix. I'm not sure what he was thinking, to be > honest. The idea is to move the registration files into a directory which is r/w for the user which likes to use Mozilla. The "tricky" point is that this must not be a file shared by all users, otherwise corruption will occur sooner or later. Solaris FNS/XFN implementation has a nice feature somewhere burried in the automounter which links /xfn/thisuser/fs/ everytimes to the homedir of the requesting EUID. The idea is simple (uhm... for people with FNS/XFN/NIS+ programming experience... =:-): 1. List /xfn/thisuser as user "snail": -- snip -- snail@castor/home/snail% ls -ld /xfn/thisuser lr-xr-xr-x 1 root root 1 Apr 3 18:43 /xfn/thisuser -> user/snail -- snip -- 2. List /xfn/thisuser as user "mozilla": -- snip -- mozilla@castor/home/mozilla% ls -ld /xfn/thisuser lr-xr-xr-x 1 root root 1 Apr 3 18:46 /xfn/thisuser -> user/mozilla -- snip -- /xfn/user/${LOGNAME}/fs/ is always an equivalent for ${HOME}. The Mozilla binaries cannot use $HOME - but /xfn/thisuser/fs/ may be used instead to access users home directory. Create softlinks for the registration files which need r/w permissions and link this stuff to a temp. dir in users home dir (CDE users may use /xfn/thisuser/fs/.dt/tmp/) or /xfn/thisuser/fs/.mozilla/ (question is if registration is "smart" enougth to create non-existing dirs first...)... Thanks all... :-) P.S.: this only works if FNS/XFN has been configured first - othwise /xfn directory is mainly empty... ;-((

> The Solaris workaround posted by Roland should not be necessary, just as it > isn't necessary on any other Unix. I'm not sure what he was thinking, to be > honest. The idea is to move the registration files into a directory which is r/w for the user which likes to use Mozilla. The "tricky" point is that this must not be a file shared by all users, otherwise corruption will occur sooner or later. Solaris FNS/XFN implementation has a nice feature somewhere burried in the automounter which links /xfn/thisuser/fs/ everytimes to the homedir of the requesting EUID. The idea is simple (uhm... for people with FNS/XFN/NIS+ programming experience... =:-): 1. List /xfn/thisuser as user "snail": -- snip -- snail@castor/home/snail% ls -ld /xfn/thisuser lr-xr-xr-x 1 root root 1 Apr 3 18:43 /xfn/thisuser -> user/snail -- snip -- 2. List /xfn/thisuser as user "mozilla": -- snip -- mozilla@castor/home/mozilla% ls -ld /xfn/thisuser lr-xr-xr-x 1 root root 1 Apr 3 18:46 /xfn/thisuser -> user/mozilla -- snip -- /xfn/user/${LOGNAME}/fs/ is always an equivalent for ${HOME}. The Mozilla binaries cannot use $HOME - but /xfn/thisuser/fs/ may be used instead to access users home directory. Create softlinks for the registration files which need r/w permissions and link this stuff to a temp. dir in users home dir (CDE users may use /xfn/thisuser/fs/.dt/tmp/) or /xfn/thisuser/fs/.mozilla/ (question is if registration is "smart" enougth to create non-existing dirs first...)... Thanks all... :-) P.S.: this only works if FNS/XFN has been configured first - othwise /xfn directory is mainly empty... ;-((

Updated release notes should mention bug #45699 -- plug-ins can't be installed on a per-user basis. That seems to be the most serious remaining issue related to this. (As always, IMHO....)

This bug does not depend on the ``install to homedir'' bug (56811). I think that bug should be marked WONTFIX or FIXED, since the release notes currently do the (wrong) thing that's mentioned in there. The W2K-specific (and Netscape-specific!) issues in 56249 are well-described in that bug, and I think discussion of that issue should be moved there. Ditto for 54904, which is a request for a better solution to Myth's installed-chrome hack. 49272 is basically the same bug. 39808 is a non-bug, as far as I can tell: the XPT caching code does what XPCOM does, so use of regxpcom is sufficient. So, I'm closing this bug, because it's a horrible waste of people's time. Nobody, it seems, is willing to read the complete history. I've filed bug 74574 to track the release note change; please cc: yourself to your heart's content. (Matthew: the 4xp plugin-install issue will certainly be mentioned. Thanks.)

Mike: > How can you be ``sure as hell'' that Blizzard's techniques won't work on > Solaris, when you are apparently completely ignorant of those techniques? I was referring to specific RPMs for Linux, that obviously will not install or run on Solaris. Furthermore I have only used release builds from mozilla.org (mirrors). The post-install procedure described by Myth I will try as soon as 0.8.1 for solaris/sparc is available.

Reinout: the binary RPMs wouldn't work, but the source RPMs actually might -- RPM is available for Solaris and many other platforms (see http://www.rpm.org/). But that's not the real point -- the *techniques* used certainly would work.

changing QA contact

"Release notes should better describe multi-user installation process" Bug is marked as FIXED -- this just does noot like it is .... Or alternatively Summary is incorrect and "Release notes should better describe multi-user installation process" belong to some other bug. mozilla-installer/README on BUild ID 2001122108 reads: ======================================================================== *Installation Instructions -- Unix 1.Create a directory named "mozilla" and move the tar.gz file into the mozilla directory. mkdir mozilla; mv mozilla*.tar.gz mozilla 2.Change to the mozilla directory and untar the archive. This will create a directory called "package". cd mozilla; gzip -dc mozilla-i686-pc-linux-gnu.tar.gz | tar -xvf - 3.Change to the "package" directory. mv mozilla*.tar.gz ../ ; cd package 4.Run the Mozilla Preview Release software with the run script: ./mozilla ========================================================================== mozilla-installer directoru is created when extrack mozilla-i686-pc-linux-gnu-0.9.7-sea.tar.gz . That text is zero relevance to that what need to be done. Instead I do wollowing: cd mozilla-installer directory Run mozilla-installer as root.

posted Bug 116669 references to mozilla directory should be changed to mozilla- installer based on comment 151. If people have issues small or large they should file new bugs.

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

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