when you use the installer on win32, it will run the application with "-installer" so that we migrate the profiles. linux isn't doing this. (I'm not sure what mac does.) I think we need to do this from rtm. question: if the user has already migrated, and they use the Installer again, will we migrate again, or is that not a problem. (I guess my question is if we run -installer multiple times, do bad things happen?)

Nominating for rtm per Seth. Maybe Bhuvan or Don can answer Seth's question.

This will also cause the component.reg to get generated at install-time solving the problem where root installs, doesn't run, and subsequent lowly users who run don't have permission to generate the component.reg so they can't launch successfully.

We've gotta fix this, 4.x stuff doesn't migrate *and* it causes the app not to start (see bug 41057) without a non-obvious workaround.

we always run ProfileExists() check before we decide to migrate the profile information when one runs the app with -installer. So, no bad things should happen. The only side effect I know is that you after migrating (say profile foo), you rename your profile in 6.0 to something else (say to profile bar), Now when you run the -installer again you migrate the foo as no profile with such a name is found 6.0 registry. There is bug addressing this issue. This is a very corner case.

So, one thing I forgot to mention is that if the profile exists, then we return OK and just don't do anything in the profile information migration part of the code. (it is equivalent to running the app without -installer commandline option).

PDT marking [rtm need info] so it doesn't mess up our queries :-)

PDT's move just messed up *my* queries so adding [sgehani+] to bring back on my radar.

Please note that thus bug is would regress bug 42184, and thus can only be a temporary fix.

I see this as required *because* of bug 42184. Launching mozilla from the installer takes care of performing all the "1st run" tasks that 42184 says should go away. As it is we're getting lots of complaints from people who understandably don't know about or understand this requirement and then can't run the product.

Daniel, are you talking about bug 41057? Because bug 42184 is "Do not require to run mozilla-bin as root, not even during installation", and "mozilla -installer" *is* mozilla-bin, not?

Regardless of how much it's hated, bug 42184 exists. That's how we initially designed the product and it will take a lot of work to change. Until it is fixed people get messed up who don't know about that requirement. This bug describes a way to make sure the workaround for bug 42184 happens, helping the inexperienced at the cost of annoying people like yourself even more :-) If you like you could open a new bug to *not* launch mozilla from the installer, blocked by 42184. We could also (or instead) add an argument to the installer instructing it not to launch at the end, or even decide (based on newsgroup discussion) that Mozilla is only for the experienced who will have to deal with bug 42184 in their own way.

Daniel, apart from your last sentence, I agree, and it is exactly what I meant with "Please note that thus bug is would regress bug 42184, and thus can only be a temporary fix."

r=ssu

Fix looks good, a=dveditz (module owner). It's big, but is essentially a new feature for the linux installer based on all the bad feedback from people who couldn't run afterwards due to the permissions problem. Not to mention the lack of migration.

I thought I deputized dveditz on this stuff already. His a= is better than mine here. /be

Putting on PDT's radar.

This is more than Giagantic for this point in time (re: landing on N6 branch). We need some assurances that this is ABSOLUTELY off the codepath for *EVERYTHING* except the run of the install. There must be no fundamental changes... just a glued on feature. Please come to the 3pm PDT meeting with evidence and assuredness. This is much too late for adding features :-(. I'm not even convinced that a PDT invitation is in order, but I want more general PDT concensus on this.

This is lower risk than it looks cause it only happens *after* download and installation has occured. If it fails it will do so silently.

PDT, Based on voicemail to Mike (LaGuardia) he supports this bug because as stated: 1> The build may not be usable since autoreg didn't happen when root installed and subsequently a non-root user who has no write permissions to the central /usr/local/{netscape,mozilla} directory runs the product. A potentially non-usable build is a bad thing. 2> Profile migration doesn't happen (an entire feature is missed on unix) because users will not know to run with the special "-installer" flag to enable profile migration.

PDT marking [rtm need info]. Dan and Samir to generate matrix of test cases and let us know when they've proven that this big patch is safe.

Dan and I discussed this further. There really is only one test case: 1> Create a 4.x profile. 2> Run the Netscape 6 Linux installer as a privleged user (say root). * The profile migrates (may not see visual feedback) * Activation occurs 3> Exit Netscape 6. 4> Change to a non-priveleged user. 5> Run Netscape 6. * It should run * All expected items should show up in the Task menu

keep in mind, when you run with -installer we look in $HOME for a .netscape directory. so, if I install as root, it will try to migrate root's ~/.netscape to root's ~/.mozilla (which is ok, some people use Netscape as root.) but if other users use 6.0 at a later time *with out the -installer flag*, their profile will not migrate. (the user won't see the root profile, since it lives in root's $HOME/.mozilla) I think the way to solve this problem is to always execute as if the user did -installer. (there is another bug that discusses the pro's and con's of this, cc'ing selmer and alecf who have been discussing it.) the remaining problem would be: if you install as root, will we have problems running mozilla later when it tries to write to the component.reg and other files that live where you installed the application?

see bug 56572. to solve the problem I mentioned, I think we could do this: check if there is a $HOME/.mozilla (or whatever for your platform) if not, act like the user did -installer

rtm++

Landed fix on {{branch,trunk}x{moz,ns}}.

Wait, does the installer now invoke Navigator, now just the registration stuff? This would be very bad. Navigator defaults to a website as homepage, so root would run Navigator and fetch network content. This is not acceptable.

> , now just the s/now/not/ I only realized that Navigator is ran when you spoke about activation.

If there is strong opposition to this we could easily turn it off in mozilla.

Can we just run the registration for Mozilla, without invoking Navigator?

This seems really wrong to me, for various reasons already stated. If people are worried about root installs and non-root operation, the right fix is to follow blizzard's RPMs, as mentioned in 41507. You don't need to run mozilla to make component.reg and the chrome stuff work, you just need to run the reg* twins. Auto-migrating root's .netscape to .mozilla, and thereby fetching and interpreting network content as root, is very wrong. I'm a little surprised that this got past jar, since he's been a security hound for ages. Why isn't this an optional thing, with a checkbox? [X] Migrate Communicator 4.x profile to Mozilla for $USER I think this should be backed out of the Mozilla tree: it's the wrong approach, and it doesn't actually solve the stated problem (as seth points out).

I'm not sure, but I *think* that the root's profile is not migrated during the running of "netscape -installer", rather basic templates are established. Can someone comment about the difference (if any) between the install, and the first running of the app? If I understand Shaver's concern, it is for the lack of distinction between an "administrative install" (landing files in system directories) and the "install for user with ID root" (which migrates existing user's prefs etc.).

if root has a $HOME/.netscape directory, and if the Installer runs mozilla with -installer after installation, we will migrate root's .netscape to $HOME/.mozilla

-installer is poorly named. think of it as -migrate-4x-profiles

I am convinced by the security arguments presented that running just regchrome and regxpcom rather than lauching the product is safer. Changing the current code from running "netscape -installer" to running "regchrome" *and* "regxpcom" is a trivial, low impact change. If approved I will gladly make these changes. Someone who feels strongly enough will need to open a new bug justifying the change with the security concerns and get approval for me to check this in. Regarding profile migration: we could either document the -installer flag (not sure how many users this information will reach) or silently attempt it every time. However, I believe the profile migration decision is already being discussed in bug 56572 per Seth.

> Someone who feels strongly enough will need to open a new bug justifying the > change with the security concerns and get approval for me to check this in. I'll just reopen this one, based on "fix not satisfying". Clearing Status whiteboard ([rtm++] and stuff). Alternate fix would be to back the change for this bug out and fix bug 56811.

We should not be changing the general behavior, only the "broken" case. In the case of the user having root privileges, it would be OK to put up a confirmation dialog. For normal users, the normal behavior should be just fine. I don't believe automigration on every run of the product is the correct solution. Let's not add work and risk around this right now. We should take the smallest fix that addresses the actual problem.

Selmer, I thought, the main reason for this bug was the registration, not migration. If Mozilla is installed as root (without the registration), and then ran as user, we might have all the problems of bug 42184 again.

Here are the multiple problems described in this bug: 1. The original problem - installer doesn't run -installer on Linux 2. Component registration as root is required/incorrect for certain installs 3. Should not require root user to run app during install 4. Should not migrate root's profile? Should migrate root's profile? 5. non-root users do not get migrated automatically 6. Registration happens for Mozilla users and root installer 7. when root, launching app causes network content to be loaded I suspect there may be more than one bug here ;) The original request to run -installer did not address Jar's administrator vs normal user distinction. That is the fundamental problem all the comments in this bug are dancing around. The existing -installer behavior is predicated on being run by a normal non-admin user on their own behalf. The first fix should be to elminate the non-install portion of the task when run as root. In this case, we should do component reg etc, but not migration or execution of the product during the -installer launch when the user executing the binary is root. The second fix should be to give the root user a new flag that allows her to migrate her profile. Alternatively, the first fix could include a dialog that asks whether to do this action. The third fix should be Seth's proposal that non-root users *with* a ~/.netscape directory and *without* a ~/.mozilla directory should get the -installer behavior automatically. This case is unique on the multiple platforms in that the state of these directories is sufficient by itself to distinguish the -installer case from the normal run case. The fourth fix is that for Mozilla, we should never do migration automatically. It was decided long ago that this should always have a dialog on Mozilla builds. Sounds like that may have gotten broken on Linux somehow. It should be fixed. I believe these proposals together should address all the many problems described in this bug.

> when run > as root. In this case, we should do component reg etc, but not migration or > execution of the product during the -installer launch when the user executing > the binary is root. As Seth said, the -installer flag *is* intended for migration. If you need only registration, you can do that via regxpcom et al. (so I heard). See the latest comment in bug 42184. > The third fix Covered by bug 56572. > The second fix should be to give the root user a new flag that allows her to > migrate her profile. If somebody does indeed use Mozilla as root regularly, we shouldn't helping her with such features to make it work smooth. > The fourth fix is that for Mozilla, we should never do migration > automatically. When I tested it last days, a dialog came up. So, no peoblem here, I think.

Ben, sorry if you read a suggested implementation into my comments. None was intended. However, I disagree with your statement that we should make life difficult for root users simply because you don't like them running the app with those privileges. As root users, I believe it is *their* responsibility, not *ours*, to make such decisions. So, it seems that the remaining fix revolves around how to handle root users running the installer and other bugs cover the other problems.

selmer, I'm not saying we should make it difficult. We just shouldn't work to make it easy. (BTW: IIRC, 4.x on some distro (FreeBSD?) refused to run as root.) Anyway, you said: > The second fix should be to give the root user a new flag that allows her to > migrate her profile. If we leave the -installer flag alone, root already has this flag (just like every other user). He just has to invoke it manually (which seems OK to me, see above). So, we have 2 options: - Create a new flag for mozilla-bin, which just makes the registration and then exits. This can only be a temporary fix, for reasons stated in bug 42184. - Fix it the right way (i.e. fix bug 42184 - it has a patch, which is claimed to work) and leave this bug alone. This is my proposal. In any case, the current fix has to be backed out.

The 4.x claim about root and FreeBSD is simply not true. There were no platform-to-platform policy differences between unices. The current fix breaks users who "su" to root, but I would say (and it sounds like Ben, you agree) that this is the common case, and that -installer turns out to be the wrong thing after all. I agree that we should back out this fix, and concentrate on bug 42184.

> The 4.x claim about root and FreeBSD is simply not true. There were no > platform-to-platform policy differences between unices. Distributions can change the wrapper script, and this is what they did, IIRC.

What is this root, does it only cover linux? does it mean any user whose userid is equivalent to root? would it cover windows nt w/ any sort of administrator account? </mock type="pp"> -installer should not special case root. If root has a netscape4 account then root wants to be able to use it. Of course we should set up the default on all (multiuser?) systems to use regxpcom and regchrome [which should work on win32] instead of -installer If the run-mozilla.sh script wants to warn root that -installer will run migration, activation and start mozilla that's fine. For the sake of this bug asis, do we intend to undo it and then resolve wontfix? [i think that's our conclusion]

I agree: this should be backed out of the Mozilla trunk (Netscape can decide about the branch, obviously), even before we get the installer properly calling regxpcom and regchrome, or the appropriate APIs directly. samir: if you're concerned about problems getting Netscape to authorize you to work on that backout, please reassign the bug to me.

How we fix this one would seem to depend in part on Seth's fix for bug 56572. Reassigning to him for now, reassign back to Samir when you figure out how you want the installer to behave.

I've got a fix for 56572. getting it reviewed now. my fix (if accepted) will mean that the installer will not have to run -installer. it would do nothing about the "we only need to run regxpcom and regchrome" issue

talk to dveditz. this is going back to samir. here are the two big problems: 1) application installed as root, but then no user can run the application later, except root 2) application installed as root, then user has to know about -installer to migration from 4.x samir's fix for #1 solves this problem. (***see below for more comments) when I check in my patch for 56572, #2 will be fixed. *** should the installer launch the app with -installer, like we do on win32 and linux. if the user installs using the installer (and not rpms or the .tar.gz) as root, is this a problem? if the user installs as themself, say into ~/bin, is this a problem? is this the desired behaviour? if the installer only ran regxpcom / regchome (as root), is that any safer? on a related note, if the user installs from rpm's or from the tar.gz file as root, can they run later as another user?

> should the installer launch the app with -installer, like we do on win32 No. > if the user installs using the installer (and not rpms or the .tar.gz) as > root, is this a problem? Yes, for the reasons given above. (Summary: Even though running a GUI installer as root is not very safe, running mozilla-bin as root is worse. What makes it really evil, though, is that this lanches Navigator, which fetches and evaluates network content.) > if the user installs as themself, say into ~/bin, is this a problem? No, *but* only if "user" in the "mortable" sense. Some systems (common on Solaris, I heard; also done on some Linux systems) use a special user for installations. E.g. root maintains the hardware, "system" owns system apps and "packages" installs and owns /usr/local and /opt. You don't know which type of user this is, because it is only an administration policy. *If* we knew reliably that a real user is running the installer, I would be OK to run th apps after the installation. (But personally, I am not too big a fan of this. I am still able to start apps myself, when I want to ;-P .) > if the installer only ran regxpcom / regchome (as root), is that any safer? Yes, a lot. reg* are minimal commandline apps, which can (much more) easily be checked and ensured to do the right thing, even if ran as root. > on a related note, if the user installs from rpm's or from the tar.gz file as > root, can they run later as another user? blizzard's RPMs allow this. this is because the package runs a script after installation which calls regxpcom etc..

Ok, I'm declaring this bug dead. As described this bug is FIXED and at this point we aren't going to change it in the RTM branch so this bug will document that fact for QA. Opened bug 57089 to describe what this bug morphed into, that is, to turn off the effect of this fix on the trunk and get regxpcom/regchrome going.

this is fixed in MN6 builds this week- todays 2000101808MN6 marking vtrunk to see what trunk outcome is

verified on trunk build 2000111706