198715 - [MachO] not all xpi's get installed for all users

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Bjarne D Mathiesen]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; da-DK; rv:1.3; MultiZilla
v1.4.0.2) Gecko/20030310 (1.3rc2)

I usually install the following *xpi's :
1) MultiZilla                 (multizilla.mozdev.org)
2) googlebox                  (multizilla.mozdev.org)
3) home                       (home.no.net/trihand/mozilla/home/en/)
4) BannerBlind                (bannerblind.mozdev.org)
5) AdBlock                    (adblock.mozdev.org)
6) enigmime-0.73.1-MacOSX.xpi (self-compiled)
7) enigmail-0.73.1.xpi        (self-compiled)

Now, my usual procedure is to install all of the above as either root or an
admin user. On my production machine, I've until the release of 1.3 been running
1.2.1 with 1) 2) 4) 5) without any problems at all

With 1.3rc2 only the following installs cross-user : 1) 2) 6) 7)
If I install all of them as root, only root has access to all of the xpi's
If I install as the default admin, the admin and root has access to all xpi's
The normal users only see the previous mentioned 4 xpi's

If I install Mozilla and the 7 xpi's in a user's home directory, the user has
access to all 7 xpi's.

This might possibly be a duplicate of one of the bugs regarding the xpi-install
engine on Mac OS X, but I couldn't see which one it might be ;-)

Comment 1

[Sean Su]

Reporter, can you try your tests with a recent nightly MachO trunk build and see
if your problems still persist?

  http://ftp.mozilla.org/pub/mozilla/nightly/

Comment 2

[Bjarne D Mathiesen]

just tried 2003-03-24-16 : problem persists
1a) installed as root
1b) no other user has access to 3) 4) 5)
2a) installed as admin
2b) no other user has access to 3) 4) 5)
2c) root has full access to all 7 xpi's

Comment 3

[Bjarne D Mathiesen]

bug still present i 1.4b (2003050714)

This bug makes it impossible to install a some xpi's system-wide

WorkAround: install Mozilla on a per-user basis

Comment 4

[Sean Su]

I had verified that under OSX, we preserve the permissions of files when
uncompressing them.  This started when we converted from CFM builds to MachO
builds (I believe it started with 1.3).

It sounds like 3), 4), and 5) might have been packaged up with the wrong
permissions set.

I did a little test with 3).  When I installed 3), it created:
  -rw-------    1 ssu  staff     9750 Dec  9 19:43 home.jar

Then when I saved home.xpi and uncompressed it's contents, unzip saved home.jar as:
  -rw-r--r--    1 ssu  staff     9750 Dec  9 19:43 home.jar

I then created my own .xpi file (I called it myhome.xpi) with the same contents
as home.xpi as follows:
 1) unzip ../home.xpi
 2) zip ../myhome.xpi *

When I installed myhome.xpi, home.jar was now:
  -rw-r--r--    1 ssu  staff     9750 Dec  9 19:43 home.jar

It looks like from my test that unzip will set the permission to a+r if the
permissions were originally go=-rwx.

You should check with the creators of 3), 4), and 5) to make sure that they are
setting the permissions correctly before creating the .xpi files.

I unzipped and installed googlebox.xpi and googlebox.jar in both cases is set to:
  -rw-rw-rw-  1 ssu  staff  53137 Mar 26 18:11 googlebox.jar
which probably explains why it works for you.

Comment 5

[Sean Su]

This is probably an evangelism bug.

Comment 6

[Samir Gehani]

Does not block bug 197105 which is a meta bug for XPInstall issues on Mac OS X
specifically relating to loss of functionality resulting from the CFM -> Mach-O
switch.

Comment 7

[Chris Casciano]

Theres something more in play here... when packaging my toolbar I initially used
the "stock" jar from the command line on OS X. While all permissions were set
properly on the initial files before they were packaged they seem to have gotten
lost somewhere in the jar process. (resulting with installs that placed filse
with either -rw------- or -r--------)

I ended up packaging with winzip on my win2k box instead cause it worked the
first time I tried it.

not saying this isn't an evangelism issue, just think things need to be flushed
out a bit more first.

Comment 8

[Bjarne D Mathiesen]

OK - based on comment #4 the fix/workaround for this ought to be :

1) install the *.xpi's you want to use
2) cd <folder-path>/Mozilla.app/Contents/MacOS/chrome
3) sudo chmod 664 *jar

Course of action :
1) take contact with the authors of 3), 4), 5) and have them take a look at this bug