Bug 250295

Created attachment 160340 [details]
Patch to fix brp-java-repack-jars for my system

Ah. This needs fixing.

Jon.

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.

I think we should not assume world readable files, this is a potential security
problem.

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.
...

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 :)

  

OT really but a patch for the ant problem is available upstream:
https://issues.apache.org/bugzilla/show_bug.cgi?id=42122

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 :)

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)

I'm no bash expert, but that looks like a different bug.

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

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.

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

See my duplicate bug for another reproduceable test case of what seems to be the same issue ...

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

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.