> Dear friends,
>
> Im my opinion there is a very serious problems with binfmt_java as
> implemented in the pre2.0 series kernels. This is particularly
> disturbing given the timings, although the problem is technically
> fairly trivial.
>
> The problem is that it assumes *way* too much about the user space
> environment. All of the following are assumed:
>
> 1. A /usr partition exists, is writable and/or the version of java
> installed there is appropriate;
> 2. /bin/bash (not even /bin/sh) exists and is appropriate for running
> shell scripts;
> 3. /usr/bin/java and /usr/bin/appletviewer are shell scripts.
> 4. It appears to me that it will not properly handle executing it from
> anywhere but the current directory, since it strips the path from
> the front.
I believe someone is in the process of putting together a generalized
interface for running various sorts of binaries. It does involve a kernel
space interface (as do the a.out and elf binary interfaces) but it is
considerably more flexible.
Definitely /proc/sys should allow control of paths used. And definitely,
no, such binary interfaces should be up by default, unless someone can
provide convincing evidence they are planning to rewrite their system
utilities in native java or postscript. ;)
>
> I would suggest one of the following approaches:
> .
> .
> .
> 3. Hardest/most flexible: set the appropriate paths through /proc/sys;
> disable Java binaries unless the paths are set.
>
> I'll try to hack up #3.
Check the archives of recent messages on linux-kernel to see if someone
really is working on the same thing. Regardless, your points seem very
cogent, and your interest in doing #3 sounds very promising, especially to
people like me who are feature drones.... :)
lilo
Canonical stupid but enthusiastic admin