Closed Bug 55419 Opened 24 years ago Closed 24 years ago

[linux only] the installer doesn't run "netscape -installer" like it does on win32

Categories

(SeaMonkey :: Installer, defect, P1)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sspitzer, Assigned: samir_bugzilla)

References

Details

(Whiteboard: [rtm need info])

Attachments

(2 files)

Patch 1 of 2: fix and mozilla Makefile.in change
9.75 KB, patch
Details | Diff | Splinter Review
Patch 2 of 2: ns Makefile.in change to keep in sync with mozilla
661 bytes, patch
Details | Diff | Splinter Review 
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.
Status: NEW → ASSIGNED
Keywords: rtm
Priority: P3 → P1
Target Milestone: --- → M19
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.
QA Contact: gemal → gbush
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.
Blocks: 41057
Whiteboard: [rtm+ need patch]
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 :-)
Whiteboard: [rtm+ need patch] → [rtm need info]
PDT's move just messed up *my* queries so adding [sgehani+] to bring back on my
radar.
Whiteboard: [rtm need info] → [rtm need info] [sgehani+]
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.

Whiteboard: [rtm need info] [sgehani+] → [rtm+] have reviewed and super reviewed patch

    
    

    
  
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.
Whiteboard: [rtm+] have reviewed and super reviewed patch → [rtm need info] have reviewed and super reviewed patch

    
    

    
  
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++
Whiteboard: [rtm need info] have reviewed and super reviewed patch → [rtm++] have reviewed and super reviewed patch

    
    

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

Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [rtm++] have reviewed and super reviewed patch

    
    

    
  
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.
Assignee: sgehani → sspitzer
Status: REOPENED → NEW
Whiteboard: [rtm need info]

    
    

    
  
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?  
Assignee: sspitzer → sgehani

    
    

    
  
> 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.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

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

    
    

    
  
verified on trunk build 2000111706
Status: RESOLVED → VERIFIED
Keywords: vtrunk

    
  
Blocks: 116669
Product: Browser → Seamonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: