openjdk team mailing list archive

[MestreLion <launchpad@xxxxxxxxxxxxxxxx>]

Public bug reported:

This is the same issue already reported for the now defunct sun-java6
package in  bug 552612 , and it also affects both OpenJDK 7 and 6. The
description below is thus very similar:

The problem is that the binfmt entry for Jar files created by OpenJDK
also matches regular Zip files and Office 2007 files. This means that if
you get these files from a FAT filesystem (typically a USB stick), or an
NTFS "data partition" (common scenario when dual-booting) then they
become 'almost' executable. Here's how to reproduce the problem:

   $ echo foo >foo.txt
   $ zip foo.zip foo.txt
   $ chmod +x foo.zip

Now on a system without java installed if you try to run or exec that
file you would get:

   $ ./foo.zip; echo $?
   bash: ./foo.zip: cannot execute binary file
   126
   $ exec ./foo.zip
   bash: /tmp/foo.zip: cannot execute binary file
   bash: /tmp/foo.zip: Success

But on a system where sun-java6-bin has been installed you get:

   $ ./foo.zip; echo $?
   invalid file (bad magic number): Exec format error
   1
   $ exec ./foo.zip
   <xterm is gone because exec succeeded>

The reason is that Jar files look like Zip files so the content matching
pattern used by /proc/sys/fs/binfmt_misc/jar matches both. The issue is
the same with the new Office 2007 files such as docx and pptx files.

Options:
1) Make the binfmt magic distinguish between Jar files and Zip files.
    This may not be possible.

2) Match based on the extension instead as documented in the kernel Documentation/java.txt file.
    This means only files with the .jar extension will be runnable which may be too limiting if the goal is to make it possible to have /usr/bin binaries actually be Java applications. However, are these really Jar files or would they be Class files? Or would wrapping them with a Class file be ok?

3) Remove the Jar binfmt altogether.
    Do the advantages of wrapper-less execution of no-extension Jar files justify changing the exec() behavior of zip and Office 2007 files? Are such files actually common?

There is also an underlying philosophical question: what should a file manager do when the user double-clicks on an executable file?
 1) fork()+exec() it and if exec() fails, then look for an association as a fallback
 2) or look for an association first and only try fork()+exec() as a fallback (or even have no fallback at all)

Nautilus seems to implement option 2 so it's not impacted by this issue.

** Affects: openjdk-6 (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: openjdk-7 (Ubuntu)
     Importance: Undecided
         Status: New

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of OpenJDK,
which is subscribed to openjdk-7 in Ubuntu.
https://bugs.launchpad.net/bugs/1172961

Title:
  update-binfmt for Jar files also impacts Office 2007 and Zip files

Status in “openjdk-6” package in Ubuntu:
  New
Status in “openjdk-7” package in Ubuntu:
  New

Bug description:
  This is the same issue already reported for the now defunct sun-java6
  package in  bug 552612 , and it also affects both OpenJDK 7 and 6. The
  description below is thus very similar:

  The problem is that the binfmt entry for Jar files created by OpenJDK
  also matches regular Zip files and Office 2007 files. This means that
  if you get these files from a FAT filesystem (typically a USB stick),
  or an NTFS "data partition" (common scenario when dual-booting) then
  they become 'almost' executable. Here's how to reproduce the problem:

     $ echo foo >foo.txt
     $ zip foo.zip foo.txt
     $ chmod +x foo.zip

  Now on a system without java installed if you try to run or exec that
  file you would get:

     $ ./foo.zip; echo $?
     bash: ./foo.zip: cannot execute binary file
     126
     $ exec ./foo.zip
     bash: /tmp/foo.zip: cannot execute binary file
     bash: /tmp/foo.zip: Success

  But on a system where sun-java6-bin has been installed you get:

     $ ./foo.zip; echo $?
     invalid file (bad magic number): Exec format error
     1
     $ exec ./foo.zip
     <xterm is gone because exec succeeded>

  The reason is that Jar files look like Zip files so the content
  matching pattern used by /proc/sys/fs/binfmt_misc/jar matches both.
  The issue is the same with the new Office 2007 files such as docx and
  pptx files.

  Options:
  1) Make the binfmt magic distinguish between Jar files and Zip files.
      This may not be possible.

  2) Match based on the extension instead as documented in the kernel Documentation/java.txt file.
      This means only files with the .jar extension will be runnable which may be too limiting if the goal is to make it possible to have /usr/bin binaries actually be Java applications. However, are these really Jar files or would they be Class files? Or would wrapping them with a Class file be ok?

  3) Remove the Jar binfmt altogether.
      Do the advantages of wrapper-less execution of no-extension Jar files justify changing the exec() behavior of zip and Office 2007 files? Are such files actually common?

  There is also an underlying philosophical question: what should a file manager do when the user double-clicks on an executable file?
   1) fork()+exec() it and if exec() fails, then look for an association as a fallback
   2) or look for an association first and only try fork()+exec() as a fallback (or even have no fallback at all)

  Nautilus seems to implement option 2 so it's not impacted by this
  issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1172961/+subscriptions