111124 - Installer complies to umask, setting incorrect permissions

Status: RESOLVED INVALID

(SeaMonkey :: Installer, defect)

Description

[Alon Altman]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914
BuildID:    Mozilla 0.9.6

I've installed Mozilla 0.9.6 and got the following error:
/usr/local/mozilla/run-mozilla.sh: line 72: 32514 Segmentation fault      (core
dumped) $prog ${1+"$@"}


Oh no!  /usr/local/mozilla/mozozilla-bin just dumped a core file.

Do you want to debug this ? You need a lot of memory for this, so watch out ?
[y/n] y
which: no ddd in
(.:/home/alon/misc-scripts:/home/alon/misc-binaries:/usr/local/bin:.:/home/alon/misc-scripts:/home/alon/misc-binaries:/usr/local/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin)
/usr/bin/gdb /usr/local/mozilla/mozilla-bin core

[snipped]

#0  0x40130f00 in nsComponentManagerImpl::FreeServices ()
   from /usr/local/mozilla/libxpcom.so
(gdb) bt
#0  0x40130f00 in nsComponentManagerImpl::FreeServices ()
   from /usr/local/mozilla/libxpcom.so
#1  0x400f96bd in NS_ShutdownXPCOM () from /usr/local/mozilla/libxpcom.so
#2  0x0804febc in main ()
#3  0x404f5530 in __libc_start_main () from /lib/libc.so.6
(gdb) 


Reproducible: Always
Steps to Reproduce:
1. Install mozilla 0.9.6
2. /usr/local/mozilla/mozilla


Actual Results:  Crash output as specified above

Expected Results:  Mozilla should have started

Comment 1

[Alon Altman]

I just noticed the bug is in /usr/local/mozilla/libxpcom.so, so I guess it has
soemthing to do with XPCOM

Comment 2

[Doug Turner (:dougt)]

Asa, are we getting any similar talkback data?

Comment 3

[Alon Altman]

No talkback data would be available, as the crash is before the TalkBack part is
loaded at all.
Mozilla 0.9.4 does not crash this way.

Comment 4

[neeti]

just pulled a debug mozilla  0.9.6 branch, I cannot reproduce the crash.

Comment 5

[Doug Turner (:dougt)]

reporter, can you debug any further?  can you reproduce consistantly?  Did you
install over a preexists version of mozilla?

Comment 6

[Alon Altman]

I can reproduce constantly. Older version of mozilla was removed prior to reinstall. I have tried renaming my ~/.mozilla directory with no success.



What more debug info do you need and how can I generate it?

Comment 7

[Alon Altman]

I found what the problem was. Installer did not set correct permissions.

I did chmod -R a+rX /usr/local/mozilla and it worked.

Reassigning to Installer team.

Comment 8

[Daniel Veditz [:dveditz]]

What permissions did the installer set?

Comment 9

[Alon Altman]

The installer gave permissions only to root, and no permissions to group and other. This is probably due to conforming with a umask(2) setting that it complied with.

Comment 10

[Chris Woods]

Attachment: transcript of running `mozilla -g', then `run' command from within gdb

I'm able to duplicate this consistently. Recommend that it be moved out of
installer category, since this occurs from a hand-compiled 0.9.7 build, and the
"chmod" workaround mentioned earlier in the report was applied.

Linux nosferatu 2.4.16 #1 Sat Dec 1 18:22:44 EST 2001 i686 unknown
gtk 1.2.10
gcc version 2.95.3 20010315 (release)
GNU C Library stable release version 2.2.4, Compiled by GNU CC version 2.95.3
20010315 (SuSE)

I'll do whatever necessary to aid in diagnosing this bug.

Comment 11

[Aleksander Adamowski]

I've had this problem when installing minirot13.xpi (see bug 66822).

However, the installed JAR file had 400 mode (read for root, no permissions for
others), although umask of root user is set to 022, which only prevents setting
write permissions for group and world on created files...

Comment 12

[James Rome]

This is still a problem in the nightly builds. The components directory only has
permissions for root.

Comment 13

[W Sanders]

Yup - many files are created in /usr/local/mozilla without world read/run
permissions. Umask needs to be 0022 or something less restrictive for install to
work. Easiest workaround is to rm -r /usr/local/mozilla, umask 0022, and reinstall.

Comment 14

[Alexander Opitz]

So the bug happens, if you install mozilla as root and try to use mozilla as an
other user?

Comment 15

[Andrew Schultz]

(In reply to comment #12)
> This is still a problem in the nightly builds. The components directory only has
> permissions for root.

that's bug 163524 and not related to this bug.

So why should the installer not comply with the umask setting?  The whole point
of umask is that it sets the permissions for new files.  You get what you ask for.

Comment 16

[Alon Altman]

Because it's useless to have a system-wide install accessible only to root. The
permissions should be set to read/execute for all, write for owner(root).

Comment 17

[Andrew Schultz]

(In reply to comment #16)
> Because it's useless to have a system-wide install accessible only to root. The
> permissions should be set to read/execute for all, write for owner(root).

I agree it's useless, but it's also what you asked for.
Additionally, a user could install as themselves and (for some reason) not want
other people to be able to use their installation of Mozilla.

Comment 18

[Alexander Opitz]

At first we must find, why the permission is set so stupid ... cause the line in
question seems be correct ... it tries to set 0755. maybe the installer set it
correct but the first run do something stupid.

But i haven't tried yet the installer as root and I'm not planning to do this in
the next time cause of MNG.

@Andrew Do you want to take this bug?

Comment 19

[Andrew Schultz]

the relevant peices (In reply to comment #18)
> At first we must find, why the permission is set so stupid ... cause the line in
> question seems be correct ... it tries to set 0755. maybe the installer set it
> correct but the first run do something stupid.

the relevant peices of code (there are two, one to make the "mozilla" dir and
one to make subdirs) are making mkdir() calls.  mkdir() is subject to umask
restrictions.  The code to make the mozilla directory does a lot of umask
dancing, but I don't know what the dancing is for and (AFAICT) it has absolutely
no effect.

to find out why the umask is set to something "stupid", ask the sysadmin that
set their umask.

> @Andrew Do you want to take this bug?

Forcing a 0022 umask would be easy, but I'm not convinced it's The Right Thing.
 If I were to change anything here, it would be to rip out the umask dancing,
which will not "fix" this bug.

creating mozilla directory (complete with dancing!):
http://lxr.mozilla.org/mozilla/source/xpinstall/wizard/unix/src2/nsSetupTypeDlg.cpp#798
creating subdirectories.
http://lxr.mozilla.org/mozilla/source/xpinstall/wizard/unix/src2/nsZipExtractor.cpp#166

Comment 20

[Alexander Opitz]

@Andrew

Puh ... that's very confusing.

We should make it possible for root to deside if he want to use his setted umask
or if we should handle the right mask for a 'all user can use this mozilla'.

(Does mkdir(file, 0755) creates a file with 0755 or does it depend on umask?)

Are you on irc.mozilla.org?

Comment 21

[Andrew Schultz]

(In reply to comment #20)
> We should make it possible for root to deside if he want to use his setted umask
> or if we should handle the right mask for a 'all user can use this mozilla'.

are you saying the installer should detect that the umask is set to something
overly restrictive (by some arbitrary criteria) and then pop up a dialog and say
"hey, your umask is set too restrictively, don't you want to change it?  Enter a
new umask below."

That's a bit disgusting.

> (Does mkdir(file, 0755) creates a file with 0755 or does it depend on umask?)

int mkdir(const char *pathname, mode_t mode);

mode  specifies the permissions to use. It is modified by the process’s
       umask in the usual way: the permissions of the created file are (mode &
       ~umask).

Comment 22

[Alexander Opitz]

>> are you saying the installer should detect that the umask is set to something
overly restrictive (by some arbitrary criteria) and then pop up a dialog and say
"hey, your umask is set too restrictively, don't you want to change it?  Enter a
new umask below." <<

I think it's enough to have a dialog that asks and shows the setted UMASK ... I
don't think we should try to find out if the umask will be good or not.

And thanks for helping to understand the mkdir command.

Comment 23

[Andrew Schultz]

(In reply to comment #22)
> I think it's enough to have a dialog that asks and shows the setted UMASK ... I
> don't think we should try to find out if the umask will be good or not.

so everyone (regardless of umask setting) should see a dialog saying that their
umask is set to (for instance) "002" and are they sure they want to proceed? 
that sounds equally bad as very few people even know what a umask is.

Comment 24

[Andrew Schultz]

actually the "creating directories" peice of code I mentioned in comment 19 only
gets used to create the xpistub temporary subdirectories.  The mozilla
subdirectories get created here:
http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsInstallFile.cpp#213

mkdir() gets called eventually

Comment 25

[Andrew Schultz]

see also bug 235781
this is headed fast for WONTFIX.

Comment 26

[Tony Mechelynck [:tonymec]]

"Fast", he said. Then four years went by.

There is no installer on the trunk anymore, si I think this bug has become INVALID.