189905 - Under linux have installed files incorrect permission when XPI is made under windows (with bad permissions)

Status: RESOLVED WONTFIX

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

Description

[Met - Martin Hassman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; cs-CZ; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; cs-CZ; rv:1.3a) Gecko/2002121215

Some projects from www.mozdev.org have after installation incorrect file
permission. This means .jar files installed in $MOZILLA/chrome directory have
premission like rw-------. So you must manually change it ro usefull rw-r--r--.

After some experiments, I think, I have localized the problem (but still do not
understand why it is so).
All depends on, how author of the project create its XPI file. If is .xpi file
packed using zip under windows (I have test is using zip in WindowsCommander),
then this problem under linux occures. But when is XPI file packed by zip (by
zip not by gzip of bzip!) under linux (I have test it under RedHat 7.3) this
problem never occures and installed .jar file (form .xpi file) has good
permission rw-r--r--.

It seems that there is some difference between windows and linux zip packing?
but this is strange. Maybe the bug is in the installer which incorrectly handle
the permissons under linux.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Robert Kaiser]

This is from an answer I did on such a problem:

Anyway, I think that the XPInstall functions addDirectory() and addFile() should
either set the "r" bits for user/group/others automatically, or the functions
should be able to take an argument to set permissions. Another possible solution
might be an additional function to set permissions.

To summarize, I see three ways how we could deal with that problem:
1) addDirectory() and addFile() should set the "r" bits for user/group/others
   and make all installed files readable for everyone (add an "x" bite as well
   for directories!)
2) those functions should be able to take an argument to set permissions
3) additional function to set permissions

After thinking about it for a while, I think that 1) would be the best way to do
it, as it would require no additional work for people making XPI packets, and we
would always have the problem with people create the packets only on win32 and
don't know about unix issues. As the packs and the system should be XP (as in
cross-platform), creators of XPI packs shouldn't have to care about different
platforms.

It would be nice to have 2) or 3) additionally (I'd prefer 3), but I beleive
it's best to go with 1).

Comment 2

[R.K.Aa.]

is bug 189940 a dup?

Comment 3

[Gustavo Jr. Alves]

*** Bug 189940 has been marked as a duplicate of this bug. ***

Comment 4

[Met - Martin Hassman]

Some idea.

I have looked to the
http://lxr.mozilla.org/mozilla/source/modules/libjar/nsZipArchive.cpp#642 to the
nsZipArchive::ExtractFile

And I think the problem is here on the line 665 bellow

657 #if defined(XP_UNIX)
658   else
659   {
...
664     //-- set extracted file permissions
665     chmod(aOutname, item->mode);
666   }
667 #endif


Mozilla sets for the new file the filepermission extracted from the zipfile. But
when the zipfile was packed under windows, the permission in the zipfile are
incorrect.

I think in each zipfile is some attribute, which means on which operating system
was this file packed. So solution should be simple - test if file was packen
under linux(unix) and if not, set some defaul premission to the new file (like
rw-r--r--) or read this from the uumask system variable.

Can anyone more familliar with Mozilla coding look at this?

Comment 5

[Met - Martin Hassman]

I have hints:
a) One way how to solve this should be to read OS type on which the file was packed:
This is in http://lxr.mozilla.org/mozilla/source/modules/libjar/zipstruct.h
ZipCentral->version_made_by

If so, you must add new item for this to the nsZipItem, copy here the value from
ZipCentral->version_made_by in nsZipArchive::BuildFileList and in the 
sZipArchive::ExtractFile check this before calling chmod()

b) Second way is more simple. Test for consistency of
ZipCentral->external_attributes and if it seems wrong (e.g. zero - I think this
is for many windows zipfiles), set some good premission e.g. 644.

Comment 6

[Jens Bannmann]

(In reply to comment #5)
> b) Second way is more simple. Test for consistency of
> ZipCentral->external_attributes and if it seems wrong (e.g. zero - I think this
> is for many windows zipfiles), set some good premission e.g. 644.

Should Mozilla perhaps default to the permission bits used for the main
executable? Read: if "group" or "all" is allowed to start Mozilla, extensions
should be readable by them, too, so that Mozilla *can* start.

Comment 7

[Andrew Schultz]

*** Bug 242049 has been marked as a duplicate of this bug. ***

Comment 8

[Andrew Schultz]

So how is the XPI engine supposed to decide what is executable?

Comment 9

[Bug Filler]

(In reply to comment #8)
> So how is the XPI engine supposed to decide what is executable?

I think XPI should only handle files with bad permission. like someone said 000
for permission. if bad permission is found, umask should be used to be default mode.

Set default to 0644 is bad because maybe some XPI install some config files
which some user don't want other people to see, i.e. some people set their home
directory user rw only.

Comment 10

[Robert Strong (they/them - no direct email)]

I just tested this on Windows with WinRAR and 7-Zip after performing a chmod to
my extensions files using cygwin. It appears that 7-Zip retains the permissions
while WinRAR still doesn't.

Comment 11

[Daniel Veditz [:dveditz]]

The xpinstall script engine has been removed from the trunk, bugs in it are obsolete.