[
https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544392
]
Aaron Digulla commented on DERBY-3083:
--------------------------------------
> No, my argument is that there is a vulnerability, thus it is subject to be
> being exploited.
Okay, let me see if we're on the same track here: A Security Manager will do
this: It will enforce allowed operations on specific JARs on the classpath. The
JARs are not signed and not protected in any way other than their name and path.
So Daniel's arguments boils down to this: "I enhance security by enforcing the
JAR to have a certain name/path". I do not believe this is true. As long as I
can add malicious code to the JAR without the SM noticing, enforcing the name
will not give additional protection. Therefore, enforcing a specific name will
only add a false sense of security which isn't really there. This is even more
dangerous than having an unknown vulnerability since people will believe they
are safe when they are not.
To be as safe as we can possibly be, I suggest that you use Class.getResource()
on specific classes which should be on the classpath and strip the package and
class from the resulting URL. This will be as safe as the static JAR names (as
to my argument above) and it will work for both the case that the JARs have
been renamed and that they have been collected in an ueberjar.
For the same reasons, storing these URLs in the system properties (or any
global variable) is okay too, because this cannot be exploited from a remote
attacker and the SM doesn't give any protection against a local attacker
anyway. As long as users use the supplied code, they will be perfectly safe as
long as no one can modify the classpath when the server is started. If they
embed the code in a larger app, they have to think about security themselves;
we aren't able to forsee what they might do and therefore, we can't make their
code secure for them at this time.
> Network server demands a file called "derbynet.jar" in classpath
> ----------------------------------------------------------------
>
> Key: DERBY-3083
> URL: https://issues.apache.org/jira/browse/DERBY-3083
> Project: Derby
> Issue Type: Bug
> Components: Tools
> Affects Versions: 10.3.1.4
> Reporter: Aaron Digulla
> Attachments: derby-3083-01-requireDerbynet-aa.diff,
> derby-3083-01-requireDerbynet-ab.diff, derby-716-10-datatypesCollation-aa.diff
>
>
> The network server will not start if the derbynet jar is added under a
> different name than "derbynet.jar" to the classpath. This makes it impossible
> to use it in maven projects where the jar is renamed to
> "derbynet-10.3.1.4.jar".
> This did work with 10.2.2.0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
