db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5357) SQLJ.INSTALL_JAR shouldn't use identifier as file name
Date Fri, 02 Mar 2012 15:05:57 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220974#comment-13220974

Rick Hillegas commented on DERBY-5357:

Hi Dag,

I agree that this vulnerability should be fixed. I believe that these identifiers are used

1) sqlj_install_jar

2) sqlj.remove_jar

3) sqlj.replace_jar

4) and in the database classpaths bound to the derby.database.classpath property

Unfortunately, I believe that your patch can break (2) and (3) for jar files which were stored
prior to release 10.9. I don't think that the patch addresses (4).

Here are some other approaches to consider:

A) Raise an error if the identifier passed to sqlj.install_jar contains suspicious characters.

B) Don't touch the identifier stored in SYSFILES.FILENAME. Instead, your regular transformation
could be applied to FILENAME at the last possible moment when the file is actually copied,
dropped, replaced, or included on the classpath. This approach would need to be used only
for jar files which were installed or replaced by 10.9 or later. That, in turn, would require
tagging jar files with version information. It might be possible to encode that information

C) This is a variation on (B). Build the copied file name from SYSSCHEMAS.SCHEMAID and SYSFILES.FILEID
rather than SYSSCHEMAS.SCHEMANAME and SYSFILES.FILENAME. Again, this could only be done for
jar files installed/replaced by 10.9 and later releases and would also require some way of
tagging the file with a Derby version number.


> SQLJ.INSTALL_JAR shouldn't use identifier as file name
> ------------------------------------------------------
>                 Key: DERBY-5357
>                 URL: https://issues.apache.org/jira/browse/DERBY-5357
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Dag H. Wanvik
>              Labels: derby_triage10_9
>         Attachments: derby-5357.diff, derby-5357.stat
> When installing a jar file with the SQLJ.INSTALL_JAR procedure, it will copy the jar
file to a subdirectory of the database directory. The name of the stored jar file is based
on the qualified name specified by the second parameter in the procedure, and becomes something
like: <DBDIR>/jar/<SCHEMA>/<JAR_NAME>.jar.<VERSION>
> This naming scheme is problematic because the qualified name of the jar file is an SQL
identifier and may contain any characters, also characters with special meaning to the underlying
file system.
> One example is this call:
> ij> call sqlj.install_jar('/path/to/toursdb.jar', 'APP."../../../x/jar"', 0);
> 0 rows inserted/updated/deleted
> On Unix-like systems, this will install the jar in a subdirectory of the database directory's
parent directory, which is clearly unfortunate as the database directory should be self-contained
(an assumption used when taking backup of a database using operating system commands, or when
moving the database to another location).
> There's probably also a possibility that INSTALL_JAR fails if the identifier contains
a character that's not allowed in file names on the platform.
> It would be better if the jars were stored in a file whose name is independent of the
identifier used, so that any valid SQL identifier could be used to name a jar file in the
database without causing problems.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message