9148 - [feature] [PP]File & subdir installed with incorrect permissions

Status: VERIFIED FIXED

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

Description

[Jimmy Lee]

Build: 6/29/99 SeaMonkey Linux build

1. User trigger at http://jimbob/trigger2.html
2. Trigger http://jimbob/jars/f_addsubcomp_unixpermissions.jar
        f = Install.GetFolder("Program", "f_addsubcomp_unixpermissions");
        Install.AddSubcomponent(regName, vi, "thefolder/"+jarSrc, f, jarSrc,
                                                                        true);
3. The jarSrc, "smrtupdt.txt", had file permissions changed to -rwxrwxrwx prior
   to zipping into jar file

RESULT:
The subdirectory "f_addsubcomp_unixpermission" is created as expected.  This
subdirectory's file attributes show drwx------.

The file "smrtupdt.txt" is installed into "f_addsubcomp_unixpermission" as
expected.  The file attributes show -rw-r--r--.

The Install.log records the triggered jar test correctly.

Version registry is incomplete.  Related to bug 9053,
http://bugzilla.mozilla.org/show_bug.cgi?id=9053

EXPECTED RESULT:
The subdirectory should have the permissions, drwxr-xr-x.  The file should have
the permissions, -rwxr-xr-x.

The file was enabled to have executable properties.  This property should be
retained after the jar file is triggered.  The subdirectory should be
accessible, and the installed file should have executable permissions enabled.

Comment 1

[Daniel Veditz [:dveditz]]

There are several steps to this bug, and when I start working on it I'll
probably create separate bugs for each.

1. we need to make sure common zip tools store this info in the archive.
Signtool does, but we don't want to be dependent on that one tool.

2. We have to change libjar to read the central directory rather than the local
file headers. This mode information is stored only in the central directory.

3. Only then can we start to worry about preserving that info when we extract
the files.

4. We have to decide the rules for replacing a file -- do we use the
permissions of the file being extracted, or the permissions of the file we're
replacing? The difference could be due to something an admin did explicitly.
I'm not referring to the execute bit, but the fact that group/everyone
permissions may have been set to read-only, when the file in the archive is r/w

Comment 2

[Jimmy Lee]

I ran into something interesting that we need to consider as well.  After
remotely logging into Bindu's machine, I triggered a jar that created a
subdirectory under /tmp and added a file into the subdirectory.

Because the permissions were for the subdirectory were drwx------, I was unable
to acccess this subdirectory.  I did login as root, changed the permissions, and
verified that the file was added.

The issue or question I want to raise is what are the differences to consider
when a user versus an owner installs files.

Comment 3

[Cathleen]

reassign to Dan, per today's bug meeting.

Comment 4

[Samir Gehani]

We are now restoring permissions on Unix and Windows and handle the quirks of
the Unix "zip" utility (InfoZIP) as well as WinZip and other zip utilities. Fix
in hand: contingent upon review this will be checked in once the tree opens post
verification builds.

Comment 5

[Samir Gehani]

Fix checked in.

Comment 6

[Jimmy Lee]

Build 1999-11-08-08-M11(LINUX)

Most excellent!

Comment 7

[leger]

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine

Comment 8

[Stuart Parmenter]

this is broken again. I will attach a xpi file that worked in M13 and is now
broken at M14.

Comment 9

[Daniel Veditz [:dveditz]]

Pav fails to mention the implications: we will not be able to upgrade or 
install executables on any Unix platform.

We will not be able to upgrade Linux users to beta2

We will not be able to give SSL to M14 mozilla Linux users

Comment 10

[Daniel Veditz [:dveditz]]

resetting TFV to M14 unless the PDT team decides this is not a beta stopper. 
Adding mstoltz and warren to the CC list since they also have touched nsJAR 
code.

Comment 11

[Samir Gehani]

Fix in hand.  Awaiting review and permission to check in.

Comment 12

[Samir Gehani]

Fix checked in.

Comment 13

[Jimmy Lee]

Build 2000-02-23-08-M14(LINUX)

Looks good!