Symlinking jars is dangerous (Re: The evils of /usr/share/java/repository)
On Tue, Sep 18, 2001 at 02:15:04PM -0700, Bill Wohler wrote:
> Ben Burton <bburton@mail.math.okstate.edu> writes:
> > /usr/share/java/foo-version.jar
> > /usr/share/java/foo.jar -> foo-version.jar
>
> Tread carefully. This could have unpredictable results.
>
> The extension directory $JAVA_HOME/jre/lib/ext currently points to
> /usr/share/java, so /usr/share/java is serving as the extension
> directory.
>
> The extension class loader is very aggressive and looks at all
> classes and jars in $JAVA_HOME/jre/lib/ext *and*
> $JAVA_HOME/jre/lib/ext/* (which is probably what caused this
> repository issue in the first place). This is my impression of how
> it works after pouring over the sun.misc.Launcher$ExtClassLoader
> source.
>
> Thus, it would be a bad idea to put all versions of a jar in the
> extensions directory.
>
> Instead I'd put the versioned jar files in /lib/package (with all
> the other C versioned libraries--I don't see any reason to segregate
> them, except as noted above) and link to the desired version from
> the extension directory.
>
> Alternatively, we could put all the versions in /usr/share/java, and then
> make $JAVA_HOME/jre/lib/ext a directory containing jars linked to
> the desired version of the jar in /usr/share/java.
My turn to say "tread carefully".
Symlinking jars can be dangerous, because jars can contain a Class-path:
line in their manifests. These Class-path: lines contain relative
references to other jars. This causes two problems:
- If the packager has gone and renamed the jar, then Class-path:
references in other jars will break.
- The Class-path: reference is relative (may contain ".."). Say you
have /usr/share/java/jaxp.jar, and symlink it to your VM's lib/ext
directory. Those relative Class-path: references are going to be
relative to /usr/share/java, *not* your VM directory. So even if you
symlink one jar to lib/ext, that jar may haul in a bunch of other
jars.
Here's someone who just got burnt by symlinking jdom.jar:
http://www.servlets.com/archive/servlet/ReadMsg?msgId=143649&listName=jdom-interest
"I've just spent several days tracking a nasty CLASSPATH problem
created by an entry in the Beta 7 MANIFEST.MF entry.
..
What makes this so evil is that the JVM's under Linux resolve symbolic
links. When an symbolic link to jdom.jar is placed in some project's
lib directory, both Linux JVM's still load the ../lib/xerces.jar
RELATIVE to the REAL jdom.jar file."
> I don't think we should mess with CLASSPATH in the scripts. This is
> a user-configurable variable.
>
> I don't think /etc/alternatives is a solution here. We should do
> something similar to the C shared library versioning.
>
> In general, I think we want to continue using the extension
> directory to inject jars into java and javac.
Another point about lib/ext. The JVM treats all jars in lib/ext as
priveleged, like java.lang.*.
"By default, installed extensions are granted all security permissions
as if they were part of the core platform API"
-- http://java.sun.com/docs/books/tutorial/ext/security/policy.html
IOW, symlinking a bunch of jars to lib/ext is not the same as including
them in the regular classpath.
Now, do we really want to preclude the use of a SecurityManager in any
Debian-packaged Java app?
Really, there are so many complicated issues when you start trying to be
clever with classpaths. I don't know half of them.
I'm concerned that if Debian's java policy tries to do anything out of
the ordinary, it will cause *someone* out there grief. It will then be
very hard to rectify the situation. Look at the current situation with
/usr/share/java/repository. So IMHO, the only safe thing to do is keep a
clean classpath, put jars in /usr/share/java, and let startup scripts
choose them. If you miss the ease-of-use of a system classpath, set it
in your .bash_profile, or use something like
http://newgate.socialchange.net.au/~jeff/jpe/
--Jeff
> --
> Bill Wohler <wohler@newt.com> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
> Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian!
> If you're passed on the right, you're in the wrong lane.
Reply to: