Closed
Bug 198715
Opened 22 years ago
Closed 10 months ago
[MachO] not all xpi's get installed for all users
Categories
(Core Graveyard :: Installer: XPInstall Engine, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: mozilla, Assigned: ssu0262)
Details
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 ;-)
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/
Reporter | ||
Comment 2•22 years ago
|
||
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
Reporter | ||
Comment 3•22 years ago
|
||
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
Flags: blocking1.4?
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 6•22 years ago
|
||
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.
No longer blocks: 197105
Comment 7•22 years ago
|
||
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.
Reporter | ||
Comment 8•22 years ago
|
||
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
Updated•22 years ago
|
Flags: blocking1.4? → blocking1.4-
Updated•15 years ago
|
QA Contact: agracebush → xpi-engine
Updated•9 years ago
|
Product: Core → Core Graveyard
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•