Bug 250295 - Problem Repacking Java JARs with Wrong Directory Permissions
Problem Repacking Java JARs with Wrong Directory Permissions
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: redhat-rpm-config (Show other bugs)
11
All Linux
high Severity high
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
: Reopened
: 566528 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-31 12:56 EDT by Richi Plana
Modified: 2010-06-28 06:26 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 06:26:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to fix brp-java-repack-jars for my system (374 bytes, patch)
2007-07-31 12:56 EDT, Richi Plana
no flags Details | Diff
Grant write permissions to user before rm (416 bytes, patch)
2009-09-03 05:32 EDT, Martin Blom
no flags Details | Diff

  None (edit)
Description Richi Plana 2007-07-31 12:56:33 EDT
Description of problem:
/usr/lib/rpm/redhat/brp-java-repack-jars needs read access to the files and
subdirectories of JAR files it extracts. Unfortunately, some JAR files might
have (intentionally) files and directories with permissions that make them
inaccessible.

An example of this is when I tried to rebuild the nosrc java-1.5.0-ibm jpackage
spec.

Version-Release number of selected component (if applicable):
redhat-rpm-config-8.0.45-15.fc7
java-1.5.0-ibm-1.5.0.5.0-2jpp.nosrc.rpm

In order to provide a temporary fix, I modified brp-java-repack-jars (attached
as a patch). I am not sure if there are cases for JARs containing inaccessible
(by default) files and directories.
Comment 1 Richi Plana 2007-07-31 12:56:33 EDT
Created attachment 160340 [details]
Patch to fix brp-java-repack-jars for my system
Comment 2 Jon Masters 2007-08-20 03:05:35 EDT
Ah. This needs fixing.

Jon.
Comment 3 Richi Plana 2007-08-20 10:39:53 EDT
The reason I wondered if there were any scenarios for JARs which, as stock, come
with non-world-readable files is if it doesn't, perhaps the correct fix is to
report this upstream to IBM and maybe just put code in brp-java-repack-jars to
search for non-readable files and print out Warnings.
Comment 4 Jon Masters 2008-04-03 03:30:48 EDT
I think we should not assume world readable files, this is a potential security
problem.
Comment 5 Kostas Georgiou 2008-04-09 18:14:47 EDT
I also noticed the problem while trying to build openfire.There is nothing in
the build procedure that could be generating this as far as I can tell. zipinfo
-v on the jar shows ?--------- for the unix file attributes. I had a look at
some existing jar files from sun and I created a few by hand and none had any
unix attributes on the other hand creating a zip file on f8 with the zip command
has them. 

Is it possible that our gcj based ant is using it's own library for zip creation
which is why we get the unix extensions and due to a bug adds wrong info?

For what it's worth unzip the "broken" jars with suns jar doesn't produce any
unreadable files/dirs. 

Example entries from zipinfo -v file.jar:

broken(?) entry in jar file (generated by an ant jar task)
---------------------------

  de/javawi/jstun/util/UtilityException.class

  offset of local header from start of archive:     4017863 (003D4EC7h) 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):            2007 Jan 29 20:34:42
  32-bit CRC value (hex):                           19d779fb
  compressed size:                                  295 bytes
  uncompressed size:                                443 bytes
  length of filename:                               43 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.
....

example of what running jar by hand produces (notice the missing unix extensions)
---------------------------

  de/foo.class

  offset of local header from start of archive:     306 (00000132h) 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):            2008 Apr 9 23:02:54
  32-bit CRC value (hex):                           be753a5d
  compressed size:                                  32 bytes
  uncompressed size:                                41 bytes
  length of filename:                               52 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.
...
Comment 6 Kostas Georgiou 2008-04-09 19:38:30 EDT
OK it is ant that adds the unix file mode (pure java ant as well so it has
nothing to do with gcj). From what I can tell the 000 perms are generated in the
jar task when merging a jar file (since my jar file doesn't have any I am not
sure if ant even tries to read the existing ones since my test jar doesn't have
any) and ends up with an uninitialized entry (000) for the perms.

Considering this I think that ignoring the permissions is quite safe (they don't
even exist in jars created by jar and I don't see any API in java to even read
them so java must be ingoring them anyway).

I'll try to find some time to create a simple reproducer and get upstream to fix
ant, feel free to beat me to it though :)

  
Comment 7 Kostas Georgiou 2008-04-09 22:17:12 EDT
OT really but a patch for the ant problem is available upstream:
https://issues.apache.org/bugzilla/show_bug.cgi?id=42122
Comment 8 Jon Masters 2008-05-06 18:55:45 EDT
I'm not sure I'm 100% happy with this, but you've nicely explained your
reasoning and so I'm inclined to go along with your logic for now. I think we'll
just chmod for now, since otherwise we make archives that can't be used :)
Comment 9 Petr Sklenar 2009-06-01 12:39:03 EDT
this bug seems not fixed in rawhide:
package with jar containing file nad dir with permissions 000 
versions:
redhat-rpm-config-9.0.3-8.fc11.noarch
rpm-4.6.0-1.fc10.i386
rpm-build-4.6.0-1.fc10.i386

# rpmbuild like a nonroot:
.
.
.
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
cp: cannot stat `./resources/many': No such file or directory
cp: cannot stat `spaces': No such file or directory
cp: cannot stat `here': No such file or directory
rm: cannot remove `/tmp/bz243157-build-dct5Ky/BUILDROOT/permission-zero-in-jar-0.1-1.i386/tmp/permission-zero.jar.tmpdir.uTQjwlGpC4/resources/dir-with-no-perms/redhat-release': Permission denied
rm: cannot remove `/tmp/bz243157-build-dct5Ky/BUILDROOT/permission-zero-in-jar-0.1-1.i386/tmp/permission-zero.jar.tmpdir.uTQjwlGpC4/resources/dir-with-no-perms/redhat-release': Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.W2bJLo (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.W2bJLo (%install)
Comment 10 Richi Plana 2009-06-01 22:51:28 EDT
I'm no bash expert, but that looks like a different bug.
Comment 11 Bug Zapper 2009-06-09 05:17:04 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Martin Blom 2009-09-03 05:32:23 EDT
Created attachment 359656 [details]
Grant write permissions to user before rm

I'm still having problems with this, despite the chmod fix. rm fails. If I grant write permissions to the user (see patch), it works.
Comment 13 Mary Ellen Foster 2010-02-19 06:17:09 EST
*** Bug 566528 has been marked as a duplicate of this bug. ***
Comment 14 Mary Ellen Foster 2010-02-19 06:18:09 EST
See my duplicate bug for another reproduceable test case of what seems to be the same issue ...
Comment 15 Bug Zapper 2010-04-27 07:45:13 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2010-06-28 06:26:13 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.