Unzip 5.52 extract files without any permissions

[Philippe Vanderstraeten]

I unzip an EAR file (a zip format file). All the directories tree contained in the zipped file (the EAR) is create with RW permissions. But the files contained in this directory tree are create with NO right. ls -l give "----------". What's wrong ?

Even I I unzipped as root, no permissions are set on the files.

[Steven Schweda]

UnZip 6.0 is the current released version.

http://www.info-zip.org/

> Unzip 5.52 extract files without any
> permissions

Actual "unzip -v" output would be more
informative than "5.52". In my experience,
UnZip 5.52 tends to do what it's told in
regard to file permissions. It may be
affected by the current umask value.

umask

> I unzip an EAR file [...]

I can't see it from here. Who made it? How?
(What's an "EAR file"?)

I know of no problem in UnZip 5.52 which
would cause this result, but I'm open to
considering an actual failing test case
(preferably a small one, of course).

[Steven Schweda]

> I unzip an EAR file [...]

What happens if you use Zip to make a Zip
archive?

Note: Zip 3.0 is the current released
version, but 2.32 is pretty trustworthy, too.

[Philippe Vanderstraeten]

Thanks for your anwsers

1) unzip -v says:

UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler. Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with cc for Unix (HP/UX) on Jan 5 2007.

UnZip special compilation options:
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
VMS_TEXT_CONV
[decryption, version 2.9 of 05 May 2000]

UnZip and ZipInfo environment options:
UNZIP: [none]
UNZIPOPT: [none]
ZIPINFO: [none]
ZIPINFOOPT: [none]

2) EAR file: an EAR file is an Enterprise Application Archive. In fact this a .jar file renamed with .ear

3) umask says 02

I just rerun the script which unzip. The problem desappeared....very strange !!!. I ask to the customer if it changed something on the system...they says no.
What could happened ? How to know if there are system changes ?

[Steven Schweda]

> 1) unzip -v says:
> [...]

Ok. That all looks normal.

> I can't see it from here. Who made it? How?
> (What's an "EAR file"?)

> 2) EAR file: an EAR file is an Enterprise
> Application Archive. In fact this a .jar
> file renamed with .ear

I don't feel much better informed than I did
before.

> I just rerun the script which unzip. [...]

Same archive, or a different one?

> What could happened ?

I don't know exactly what you did, so I can't
say why anything happened.

unzip -Zv
should tell you (much) more about what's in
the archive(s), including the stored
permission information.

Without more information than I have (and
perhaps more than you have), I can't
determine why anything happened.

[Philippe Vanderstraeten]

Thanks for your help and sorry for not answering as well you need...

1) Question: what is an EAR file ?
An EAR file is a directory wich contains Java librairies, xml files, xmi files. This file is compressed using jar program. The format of this file identical to ZIP format.
So you may unzip an .ear file with unzip ou jar utility.

2) We create the EARs files under windows XP using websphere utility named: servicedeploy.
Those EARs files are then moved on an HPUX server. I then extract all files contained in thoses EARs files to change some strings inside. Then I zip the resulting directory to build new EARs files.

Example:
myXXXApp.ear ==> unzip + change in all text files the string XXX by ZZZ. Then zip all the files to get an new EAR file named myZZZApp.ear

3) output of unzip -Zv on an EAR file created under windows using servicedeploy:

MYLibrarie.jar

offset of local header from start of archive: 3506394 (003580DAh) bytes
file system or operating system of origin: MS-DOS, OS/2 or NT FAT
version of encoding software: 2.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): normal
file security status: not encrypted
extended local header: yes
file last modified on (DOS date/time): 2009 Aug 11 15:20:38
32-bit CRC value (hex): 1789aa78
compressed size: 39810 bytes
uncompressed size: 80212 bytes
length of filename: 16 characters
length of extra field: 0 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
non-MSDOS external file attributes: 000000 hex
MS-DOS file attributes (00 hex): none

There is no file comment.

4) output of unzip -Zv on an EAR file created under HPUX after string substitution and whole extracted directory rezipped with zip command:

MYLibrarie.jar

offset of local header from start of archive: 253789 (0003DF5Dh) bytes
file system or operating system of origin: Unix
version of encoding software: 2.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: deflated
compression sub-type (deflation): normal
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2009 Jul 27 13:56:38
32-bit CRC value (hex): a0ba6ab6
compressed size: 28678 bytes
uncompressed size: 35225 bytes
length of filename: 16 characters
length of extra field: 0 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (000000 octal): ?---------
MS-DOS file attributes (01 hex): read-only

There is no file comment.


I just put an extract on a file. What I can see in the output of unzip -Zv is that ALL directories inside the EAR file have their permissions set to drwxr-xr-x


Hope this help you ? Thanks

[Steven Schweda]

I don't use these programs (or much else) on
Windows, but I believe that this is the
permission/protection information in the
archive:

> non-MSDOS external file attributes: 000000 hex

If that's all it gets, then UnZip will try to
use it when extracting that file. I'd guess
that that's why an extracted file gets
all-zero permissions ("---------") on the
HP-UX system.

> Then zip all the files [...]

Another invisible command, but if the files
were extracted with all-zero permissions,
then Zip would normally record those
permissions in the new archive, which would
explain this:

> Unix file attributes (000000 octal): ?---------

If you use Zip on a file with more usual
permissions, then you should get more usual
results. For example:

dyi # ls -l vat.c
-rw-r--r-- 1 root sys 80 Mar 6 2008 vat.c
dyi # /usr/local/bin/zip fred.zip vat.c
adding: vat.c (deflated 11%)
dyi # /usr/local/bin/unzip -Zv fred.zip | grep attributes
Unix file attributes (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none

"rw-r--r--" = 0644.

So, it appears that the program which creates
your original archive is storing unfriendly
permission info in the archive. Then UnZip
uses that permission info when you extract
the files on HP-UX, so you get files on HP-UX
with unfriendly permission info. Zip then
preserves the unfriendly permission info when
you make your new archive on HP-UX.

I don't see anything in the help for Zip or
UnZip which would let you ignore the actual
or archived permission info, so, if you get
unfriendly permission info in the original
archive, then you may need to change the
permissions on the HP-UX files before using
Zip to make the new archive.

man chmod

We have had some discussion recently about
adding some UnZip option(s) to allow better
permission control when extracting files,
but so far it's only talk. So far as I know,
all UnZip has now is "-X", which would not
help in this case.

[Philippe Vanderstraeten]

Ok. I will try to make a new run of my scripts and takes log of every thing. I will try to post a full report of what happens.

[Steven Schweda]

For the morbidly curious, a related problem
popped up recently on the VMS forum:

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1364941

The experimental code offered there is not
enough to work on a UNIX system, but similar
changes to UnZip's unix/unix.c should also be
possible, and could help in this situation.

[Steven Schweda]

If you're interested in running the
experiment, fetch an UnZip 6.0 source kit
from one of the usual places, and add these
replacement files:

http://antinode.info/ftp/info-zip/unzip60/minusx/unzip.c
http://antinode.info/ftp/info-zip/unzip60/minusx/unzvers.h
http://antinode.info/ftp/info-zip/unzip60/minusx/unix/unix.c

Re-build, and then use "--X" to inhibit the
setting of any original permission values.

Default: Restore ugo permissions.
-X: Restore ugo permissions and UID/GID.
--X: Restore no permissions.

These changes are unofficial, not well
tested, UNIX-only (unless you also get the
replacement "vms/vms.c" file), and not at all
documented, and I will deny everything under
oath.