Derby
  1. Derby
  2. DERBY-2206

Provide complete security model for Java routines

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: SQL
    • Urgency:
      Normal
    • Bug behavior facts:
      Security

      Description

      Add GRANT/REVOKE mechanisms to control which jar files can be mined for user-created objects such as Functions and Procedures. In the future this may include Aggregates and Function Tables also. The issues are summarized on the following wiki page: http://wiki.apache.org/db-derby/JavaRoutineSecurity. Plugin management can be tracked by this JIRA rather than by DERBY-2109. This is a master JIRA to which subtasks can be linked.

        Issue Links

          Activity

          Hide
          Daniel John Debrunner added a comment -

          > I'm afraid I don't see the need for maintaining two independent ways to manage java routine security.

          but I think you are proposing two different security mechanisms.

          I think you are proposing that if I have a jar file then I can control USAGE on it with GRANT/REVOKE but also USAGE can be given to others without my knowledge by the dbo granting the right to set the derby.database.classpath property.

          I'm saying that if I have a jar file then the I control USAGE on it purely with GRANT/REVOKE.

          Seems to be the former is more confusing. All I'm proposing is an extension of the existing GRANT USAGE behaviour, namely USAGE on the jar must be granted to PUBLIC in order to use the jar in the public derby.database.classpath.

          I also think that security needs to be designed by what is possible for any user to do, not just what is recommended.
          While it's a clever technique to allow per-property setting to be granted to individuals, it is possible and thus must be taken into account by security related changes. In addition, the very concept of definer invoked routines is designed for this type of restricted access, so I can't see it as a "sneaky way to subvert security". And at some point Derby will support such routines, so designing with those in mind I would say is a good approach.

          Show
          Daniel John Debrunner added a comment - > I'm afraid I don't see the need for maintaining two independent ways to manage java routine security. but I think you are proposing two different security mechanisms. I think you are proposing that if I have a jar file then I can control USAGE on it with GRANT/REVOKE but also USAGE can be given to others without my knowledge by the dbo granting the right to set the derby.database.classpath property. I'm saying that if I have a jar file then the I control USAGE on it purely with GRANT/REVOKE. Seems to be the former is more confusing. All I'm proposing is an extension of the existing GRANT USAGE behaviour, namely USAGE on the jar must be granted to PUBLIC in order to use the jar in the public derby.database.classpath. I also think that security needs to be designed by what is possible for any user to do, not just what is recommended. While it's a clever technique to allow per-property setting to be granted to individuals, it is possible and thus must be taken into account by security related changes. In addition, the very concept of definer invoked routines is designed for this type of restricted access, so I can't see it as a "sneaky way to subvert security". And at some point Derby will support such routines, so designing with those in mind I would say is a good approach.
          Hide
          Rick Hillegas added a comment -

          I'm afraid I don't see the need for maintaining two independent ways to manage java routine security. I think that's going to confuse users. I think there should be one way to do this, it should be straightforward, and, if possible, it should adhere to a standard that someone has thought through carefully. I am worried about overloading the meaning of USAGE via on-the-fly designs. The following makes sense to me as the single, straightforward way to manage java routine security:

          1) derby.database.classpath is not set. As soon as you set this property, you blow a hole in your security because, now, any entry point on the system classpath can be called out-of-context.

          2) The DBA role retains exclusive power to run SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY. This prevents derby.database.classpath from being set.

          3) The only way to declare usable procedures/functions is to use the SQL Standard syntax, including jar ids, USAGE privilege, and jar-specific classpaths.

          That's a very clever technique you discovered for granting privilege to set properties on a per-property basis. However, to me it looks like a sneaky way to subvert security. Customers should be discouraged form opening that kind of security hole.

          Show
          Rick Hillegas added a comment - I'm afraid I don't see the need for maintaining two independent ways to manage java routine security. I think that's going to confuse users. I think there should be one way to do this, it should be straightforward, and, if possible, it should adhere to a standard that someone has thought through carefully. I am worried about overloading the meaning of USAGE via on-the-fly designs. The following makes sense to me as the single, straightforward way to manage java routine security: 1) derby.database.classpath is not set. As soon as you set this property, you blow a hole in your security because, now, any entry point on the system classpath can be called out-of-context. 2) The DBA role retains exclusive power to run SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY. This prevents derby.database.classpath from being set. 3) The only way to declare usable procedures/functions is to use the SQL Standard syntax, including jar ids, USAGE privilege, and jar-specific classpaths. That's a very clever technique you discovered for granting privilege to set properties on a per-property basis. However, to me it looks like a sneaky way to subvert security. Customers should be discouraged form opening that kind of security hole.
          Hide
          Daniel John Debrunner added a comment -

          > It's unfortunate that having the privilege to set one database property means that you have privilege to set them all.

          I found out this is not true. The database owner can provide a setup where a user can just modify one database property, such as derby.database.classpath. How to do it is a liitle non-obvious now, but it is possible. In the future it will become easier when "run as definer" mode is implemented for routines. So I think the assumption that being able to change a database property means one has the same powers as the database owner is an invalid one. Thus I believe that to add a jar file to derby.database.classpath should require USAGE priviledge to PUBLIC on that jar.

          The "run as definer" mode I think is a good future step to resolve a number of the security issues such as:

          • ability to set specific database properties (e.g database owner provides a run as definer routine that sets a single property, and grants EXECUTE on that).
          • ability for others to shutdown a database (database owner provides a run as definer routine that shuts the database down).
            and it's standard.

          Here's the non-obvious way to provide ability for ALICE to set the database classpath without granting EXECUTE on SYSCS_SET_DATABASE_PROPERTY

          1) database owner creates a table with a CP_VALUE column VARCHAR(30000)
          2) database owner creates a trigger on INSERT of the table with an action of
          CALL SYSCS_SET_DATABASE_PROPERTY('derby.database.classpath', NEW.CP_VALUE)
          3) database owner grants INSERT to ALICE on the table

          Now when ALICE inserts a value into the table it will be set as the database classpath. This takes advantage of the fact that triggers run as definer.

          Optional steps are:
          4) database owner creates a one argument procedure that inserts into the table
          5) database owner grants EXECUTE on the procedure to ALICE (the INSERT grant is still needed).

          The ALICE can use something like
          CALL DBO.SET_CLASSPATH('ALICE.MYJAR');

          (everything can always be solved by adding indirection

          The table can also track the history of who changed the class path when. I have a JUnit test that demonstrates this, I will commit sometime in the next couple of days.

          Show
          Daniel John Debrunner added a comment - > It's unfortunate that having the privilege to set one database property means that you have privilege to set them all. I found out this is not true. The database owner can provide a setup where a user can just modify one database property, such as derby.database.classpath. How to do it is a liitle non-obvious now, but it is possible. In the future it will become easier when "run as definer" mode is implemented for routines. So I think the assumption that being able to change a database property means one has the same powers as the database owner is an invalid one. Thus I believe that to add a jar file to derby.database.classpath should require USAGE priviledge to PUBLIC on that jar. The "run as definer" mode I think is a good future step to resolve a number of the security issues such as: ability to set specific database properties (e.g database owner provides a run as definer routine that sets a single property, and grants EXECUTE on that). ability for others to shutdown a database (database owner provides a run as definer routine that shuts the database down). and it's standard. Here's the non-obvious way to provide ability for ALICE to set the database classpath without granting EXECUTE on SYSCS_SET_DATABASE_PROPERTY 1) database owner creates a table with a CP_VALUE column VARCHAR(30000) 2) database owner creates a trigger on INSERT of the table with an action of CALL SYSCS_SET_DATABASE_PROPERTY('derby.database.classpath', NEW.CP_VALUE) 3) database owner grants INSERT to ALICE on the table Now when ALICE inserts a value into the table it will be set as the database classpath. This takes advantage of the fact that triggers run as definer. Optional steps are: 4) database owner creates a one argument procedure that inserts into the table 5) database owner grants EXECUTE on the procedure to ALICE (the INSERT grant is still needed). The ALICE can use something like CALL DBO.SET_CLASSPATH('ALICE.MYJAR'); (everything can always be solved by adding indirection The table can also track the history of who changed the class path when. I have a JUnit test that demonstrates this, I will commit sometime in the next couple of days.
          Hide
          Rick Hillegas added a comment -

          I think you're right It's unfortunate that having the privilege to set one database property means that you have privilege to set them all. We might want to revisit this decision.

          Show
          Rick Hillegas added a comment - I think you're right It's unfortunate that having the privilege to set one database property means that you have privilege to set them all. We might want to revisit this decision.
          Hide
          Daniel John Debrunner added a comment -

          > I think that giving a user the power to set all database properties is pretty much a statement that they are a DBA

          That's an interesting comment, is it the case because it should be that way, or it just happens to be so because there are security holes that have not been closed yet?

          I tend to think it's the latter. granting permission to set database properties should not, I think, implictly mean the recipient is all powerful.

          If it is decided that we don't want to close such holes then there should be clear documentation that granting EXECUTE on SYSCS_SET_DATABASE_PROPERTY allows that user to bypass all security mechanisms for that database.

          Show
          Daniel John Debrunner added a comment - > I think that giving a user the power to set all database properties is pretty much a statement that they are a DBA That's an interesting comment, is it the case because it should be that way, or it just happens to be so because there are security holes that have not been closed yet? I tend to think it's the latter. granting permission to set database properties should not, I think, implictly mean the recipient is all powerful. If it is decided that we don't want to close such holes then there should be clear documentation that granting EXECUTE on SYSCS_SET_DATABASE_PROPERTY allows that user to bypass all security mechanisms for that database.
          Hide
          Rick Hillegas added a comment -

          I think that giving a user the power to set all database properties is pretty much a statement that they are a DBA. Combine that with the restrictions on who is allowed to install jar files and I don't see much security added by requiring USAGE on the specific jars in derby.database.classpath. It is easier for me to reason about this privilege if its meaning is just defined by the SQL standard.

          I agree that jar ids only make sense if sql authorization is turned on. Thanks for bringing this up.

          Show
          Rick Hillegas added a comment - I think that giving a user the power to set all database properties is pretty much a statement that they are a DBA. Combine that with the restrictions on who is allowed to install jar files and I don't see much security added by requiring USAGE on the specific jars in derby.database.classpath. It is easier for me to reason about this privilege if its meaning is just defined by the SQL standard. I agree that jar ids only make sense if sql authorization is turned on. Thanks for bringing this up.
          Hide
          Daniel John Debrunner added a comment -

          I think USAGE should be required to add a jar to derby.database.classpath, otherwise granting permission to set a database property implicitly grants usage on all installed jars. Seems cleaner to keep the separation and have grants be explicit.

          I'm also assuming that jarid is only accepted in sql authorization mode as it doesn't make much sense without the ability to support GRANT USAGE.

          Show
          Daniel John Debrunner added a comment - I think USAGE should be required to add a jar to derby.database.classpath, otherwise granting permission to set a database property implicitly grants usage on all installed jars. Seems cleaner to keep the separation and have grants be explicit. I'm also assuming that jarid is only accepted in sql authorization mode as it doesn't make much sense without the ability to support GRANT USAGE.
          Hide
          Rick Hillegas added a comment -

          I don't have any client/server security holes in mind. Just reservations about how many knobs we have.

          Let's focus on java routine security, then. I think you're proposing that if a jar id turns up in a routine's EXTERNAL NAME, then the SQL Standard prevails. Otherwise, the old rules prevail--modulo your suggestion that, by default, derby.database.classpath is unset and this prevents all user-published routines from running. We don't know how disruptive that last point will be after upgrade.

          Let me make sure that we're on the same page here:

          WITH JAR ID

          If an EXTERNAL NAME contains a jar id, then we check for USAGE privilege on that jar file at DDL time. At run-time, the classpath is determined by SQLJ.ALTER_JAVA_PATH. USAGE privilege is also checked when running SQLJ.ALTER_JAVA_PATH.

          WITHOUT JAR ID

          If an EXTERNAL NAME does not contain a jar id, then there's no USAGE privilege to check at DDL time. At run-time, the classpath is determined by the old derby.database.classpath rules, modulo your suggestion about the default derby.database.classpath state. I don't think we need to require USAGE privilege in order to wire jar files into derby.database.classpath. I think security here is managed fine by restricting the power to change derby.database.classpath.

          Show
          Rick Hillegas added a comment - I don't have any client/server security holes in mind. Just reservations about how many knobs we have. Let's focus on java routine security, then. I think you're proposing that if a jar id turns up in a routine's EXTERNAL NAME, then the SQL Standard prevails. Otherwise, the old rules prevail--modulo your suggestion that, by default, derby.database.classpath is unset and this prevents all user-published routines from running. We don't know how disruptive that last point will be after upgrade. Let me make sure that we're on the same page here: WITH JAR ID If an EXTERNAL NAME contains a jar id, then we check for USAGE privilege on that jar file at DDL time. At run-time, the classpath is determined by SQLJ.ALTER_JAVA_PATH. USAGE privilege is also checked when running SQLJ.ALTER_JAVA_PATH. WITHOUT JAR ID If an EXTERNAL NAME does not contain a jar id, then there's no USAGE privilege to check at DDL time. At run-time, the classpath is determined by the old derby.database.classpath rules, modulo your suggestion about the default derby.database.classpath state. I don't think we need to require USAGE privilege in order to wire jar files into derby.database.classpath. I think security here is managed fine by restricting the power to change derby.database.classpath.
          Hide
          Daniel John Debrunner added a comment -

          I don't think we should require sqlAuthorization in order to run the network server by default with a security manager.
          I think the non-grant/revoke setup is still secure, just a different approach, one that trusts all authenticated users.
          Maybe there are some security holes you are thinking of for client server in this mode?

          I think the ability to use Java routines with entry points directly against classpath or JRE classes should continue to be allowed in SQL authorization mode, with the security enhancement that requires setting derby.database.classpath.

          Show
          Daniel John Debrunner added a comment - I don't think we should require sqlAuthorization in order to run the network server by default with a security manager. I think the non-grant/revoke setup is still secure, just a different approach, one that trusts all authenticated users. Maybe there are some security holes you are thinking of for client server in this mode? I think the ability to use Java routines with entry points directly against classpath or JRE classes should continue to be allowed in SQL authorization mode, with the security enhancement that requires setting derby.database.classpath.
          Hide
          Rick Hillegas added a comment -

          I like the idea that Derby is secure by default. I hope this can be squared with the community's expectations that upgrade is painless. Those, at least, seemed to be our expectations during the last release cycle.

          Let's run with your proposal that secure-by-default trumps painless-upgrade. It looks like you are suggesting that customers opt into security when they turn on authentication. I'm a little distressed that authentication does not imply that the GRANT/REVOKE machinery is turned on and that we have two independent knobs for these behaviors. We certainly need to turn both of these knobs in order to secure Java routines as described by this JIRA. It would be better if we had a single knob whose meaning was "run securely." Maybe the best we can do, going forward, is say that we recognize one setting of knobs which means "run securely" and that over time, as we plug security holes, customers who set the knobs this way will get better default security although maybe at the cost of some upgrade friction. Let me try to make this concrete by further refining your proposal:

          If the customer sets BOTH requireAuthentication and sqlAuthorization to true, then:

          1) Booting the network server installs a SecurityManager

          2) Shutdown/upgrade/encrypt database powers are restricted to the database owner.

          3) Derby ignores the setting of derby.database.classpath and, instead, manages security for Java routines according to the SQL standard.

          If the customer fails to turn on one of these properties, then:

          1') The network server fails to boot from the command line unless -unsecure is specified.

          2') Anyone who can connect to a database can shut it down, encrypt it, and upgrade it.

          3') Security for Java routines is what it was in 10.2, and Derby uses derby.database.classpath.

          Show
          Rick Hillegas added a comment - I like the idea that Derby is secure by default. I hope this can be squared with the community's expectations that upgrade is painless. Those, at least, seemed to be our expectations during the last release cycle. Let's run with your proposal that secure-by-default trumps painless-upgrade. It looks like you are suggesting that customers opt into security when they turn on authentication. I'm a little distressed that authentication does not imply that the GRANT/REVOKE machinery is turned on and that we have two independent knobs for these behaviors. We certainly need to turn both of these knobs in order to secure Java routines as described by this JIRA. It would be better if we had a single knob whose meaning was "run securely." Maybe the best we can do, going forward, is say that we recognize one setting of knobs which means "run securely" and that over time, as we plug security holes, customers who set the knobs this way will get better default security although maybe at the cost of some upgrade friction. Let me try to make this concrete by further refining your proposal: If the customer sets BOTH requireAuthentication and sqlAuthorization to true, then: 1) Booting the network server installs a SecurityManager 2) Shutdown/upgrade/encrypt database powers are restricted to the database owner. 3) Derby ignores the setting of derby.database.classpath and, instead, manages security for Java routines according to the SQL standard. If the customer fails to turn on one of these properties, then: 1') The network server fails to boot from the command line unless -unsecure is specified. 2') Anyone who can connect to a database can shut it down, encrypt it, and upgrade it. 3') Security for Java routines is what it was in 10.2, and Derby uses derby.database.classpath.
          Hide
          Daniel John Debrunner added a comment -

          But in other cases the specs indicate breaking existing applications is ok, such as booting the network server with a security manager, limiting database creation, database shutdown, upgrade & encyption.
          I think affecting exsiting applications is ok if by default it closes security holes, especially when they is an easy workaround (boot the network server with -unsecure, set derby.database.classpath to an empty string).

          I also think that opting into the secure mode is the incorrect default (as in derby.database.classpath=sys.sqlj), Derby should be secure by default and have the flexibility to reduce restrictions.

          I've also been thinking that since the various security changes assume system and/or database authentication, maybe some of the restrictions should not be enforced if authentication is not enabled.
          E.g. with no authentication:
          allow any user to create databases & shutdown the system
          allow any user to upgrade, encrypt, shutdown database
          allow any routine entry point

          and maybe
          don't boot the network server from the command line if no authentication unless '-unsecue' is set. This stops a false sense of security.

          I think this changes would make the impact on existing users less.

          Show
          Daniel John Debrunner added a comment - But in other cases the specs indicate breaking existing applications is ok, such as booting the network server with a security manager, limiting database creation, database shutdown, upgrade & encyption. I think affecting exsiting applications is ok if by default it closes security holes, especially when they is an easy workaround (boot the network server with -unsecure, set derby.database.classpath to an empty string). I also think that opting into the secure mode is the incorrect default (as in derby.database.classpath=sys.sqlj), Derby should be secure by default and have the flexibility to reduce restrictions. I've also been thinking that since the various security changes assume system and/or database authentication, maybe some of the restrictions should not be enforced if authentication is not enabled. E.g. with no authentication: allow any user to create databases & shutdown the system allow any user to upgrade, encrypt, shutdown database allow any routine entry point and maybe don't boot the network server from the command line if no authentication unless '-unsecue' is set. This stops a false sense of security. I think this changes would make the impact on existing users less.
          Hide
          Rick Hillegas added a comment -

          In order to not break legacy applications, I think we can't change the meaning of currently legal settings for derby.database.classpath. However, we could use derby.database.classpath as the opt-in signal. For instance, setting derby.database.classpath to the value "sys.sqlj" could be our signal to enforce the SQL Standard.

          Show
          Rick Hillegas added a comment - In order to not break legacy applications, I think we can't change the meaning of currently legal settings for derby.database.classpath. However, we could use derby.database.classpath as the opt-in signal. For instance, setting derby.database.classpath to the value "sys.sqlj" could be our signal to enforce the SQL Standard.
          Hide
          Andrew McIntyre added a comment -

          Unsetting Fix Version on unassigned issues.

          Show
          Andrew McIntyre added a comment - Unsetting Fix Version on unassigned issues.
          Hide
          Rick Hillegas added a comment -

          Dan wrote:

          >How about really simple?

          >derby.database.classpath - not set (default) - no user defined routines allowed
          >derby.database.classpath= (empty string) - entry points in JRE classes allowed
          >derby.database.classpath=valid path - entry points in JRE and listed jars allowed

          OK, this is progress. Still puzzling to me, though: What is the upgrade story here? In 10.2, under all of these settings of derby.database.classpath, you can publish entry points both in the JRE and on the CLASSPATH.

          >Some clarity on what "allowed" means is needed. Today when a routine is created there is no check that the class/method exists. That check is deferred to execution time of the routine. I haven't looked >to see what the SQL standard says for routines in terms of checking of if the jar, class and method exist at create time.

          Here's my reading of section 9.8 (<SQL-invoked-routine>) of part 13 of the SQL Standard:

          Syntax Rule 9 seems to say that at creation-time, the jar file needs to contain a class by the given name and inside that class (or its superclasses) there needs to be a method by the given name. However, the signatures don't have to match.

          Syntax Rule 15 seems to say that it is implementation defined whether signatures are matched at creation-time or execution-time.

          Here is my reading of section 11.2 (SQLJ_REPLACE_JAR procedure) of part 13 of the SQL Standard:

          Syntax Rules 8 and 9 seem to say that an error is raised if the CREATE PROCEDURE/FUNCTION statements cannot be replayed against the new jar file. That is, whatever the creation-time rules are, they must still be valid after replacing the jar file.

          Show
          Rick Hillegas added a comment - Dan wrote: >How about really simple? >derby.database.classpath - not set (default) - no user defined routines allowed >derby.database.classpath= (empty string) - entry points in JRE classes allowed >derby.database.classpath=valid path - entry points in JRE and listed jars allowed OK, this is progress. Still puzzling to me, though: What is the upgrade story here? In 10.2, under all of these settings of derby.database.classpath, you can publish entry points both in the JRE and on the CLASSPATH. >Some clarity on what "allowed" means is needed. Today when a routine is created there is no check that the class/method exists. That check is deferred to execution time of the routine. I haven't looked >to see what the SQL standard says for routines in terms of checking of if the jar, class and method exist at create time. Here's my reading of section 9.8 (<SQL-invoked-routine>) of part 13 of the SQL Standard: Syntax Rule 9 seems to say that at creation-time, the jar file needs to contain a class by the given name and inside that class (or its superclasses) there needs to be a method by the given name. However, the signatures don't have to match. Syntax Rule 15 seems to say that it is implementation defined whether signatures are matched at creation-time or execution-time. Here is my reading of section 11.2 (SQLJ_REPLACE_JAR procedure) of part 13 of the SQL Standard: Syntax Rules 8 and 9 seem to say that an error is raised if the CREATE PROCEDURE/FUNCTION statements cannot be replayed against the new jar file. That is, whatever the creation-time rules are, they must still be valid after replacing the jar file.
          Hide
          Daniel John Debrunner added a comment -

          Rick wrote:
          --------
          What's puzzling me right now is how to secure routines without requiring jar ids. Suppose that we do not have the SYS.ENV pseudo-jar and we let users declare routines without qualifying them with jar ids. What prevents users from publishing entry points in the JRE or on the system CLASSPATH?
          --------

          How about really simple?

          derby.database.classpath - not set (default) - no user defined routines allowed
          derby.database.classpath= (empty string) - entry points in JRE classes allowed
          derby.database.classpath=valid path - entry points in JRE and listed jars allowed

          Some clarity on what "allowed" means is needed. Today when a routine is created there is no check that the class/method exists. That check is deferred to execution time of the routine. I haven't looked to see what the SQL standard says for routines in terms of checking of if the jar, class and method exist at create time.

          Show
          Daniel John Debrunner added a comment - Rick wrote: -------- What's puzzling me right now is how to secure routines without requiring jar ids. Suppose that we do not have the SYS.ENV pseudo-jar and we let users declare routines without qualifying them with jar ids. What prevents users from publishing entry points in the JRE or on the system CLASSPATH? -------- How about really simple? derby.database.classpath - not set (default) - no user defined routines allowed derby.database.classpath= (empty string) - entry points in JRE classes allowed derby.database.classpath=valid path - entry points in JRE and listed jars allowed Some clarity on what "allowed" means is needed. Today when a routine is created there is no check that the class/method exists. That check is deferred to execution time of the routine. I haven't looked to see what the SQL standard says for routines in terms of checking of if the jar, class and method exist at create time.
          Hide
          Rick Hillegas added a comment -

          What's puzzling me right now is how to secure routines without requiring jar ids. Suppose that we do not have the SYS.ENV pseudo-jar and we let users declare routines without qualifying them with jar ids. What prevents users from publishing entry points in the JRE or on the system CLASSPATH?

          Show
          Rick Hillegas added a comment - What's puzzling me right now is how to secure routines without requiring jar ids. Suppose that we do not have the SYS.ENV pseudo-jar and we let users declare routines without qualifying them with jar ids. What prevents users from publishing entry points in the JRE or on the system CLASSPATH?
          Hide
          Daniel John Debrunner added a comment -

          I agree (and has been my assumption all along) that if a jarid is specified then the behaviour for that routine should be defined by the SQL standard.

          I'm not sure if opting in means that the ability to define routines without jars is not available though.

          DERBY-2250 and DEBRY-2252 could be addressed (following the SQL standard) without resolving how to opt-in or how to make non-jarid routines secure. Those could be separate tasks. Ie. remove the 'pseudo-jars' from DERBY-2252.

          Show
          Daniel John Debrunner added a comment - I agree (and has been my assumption all along) that if a jarid is specified then the behaviour for that routine should be defined by the SQL standard. I'm not sure if opting in means that the ability to define routines without jars is not available though. DERBY-2250 and DEBRY-2252 could be addressed (following the SQL standard) without resolving how to opt-in or how to make non-jarid routines secure. Those could be separate tasks. Ie. remove the 'pseudo-jars' from DERBY-2252 .
          Hide
          Rick Hillegas added a comment -

          Here's another crack at this:

          1) The default behavior for Derby is the current behavior with all of its security holes for java routines.

          2) To get secure behavior for java routines, the customer has to explicitly opt-in. Let's be vague about what that entails right now.

          3) If you do opt-in, then you get the SQL standard behavior:

          3a) Jar ids are mandatory.
          3b) There is no SYS.ENV pseudo-jar. Instead, to access methods in the JRE you have to include little wrapper methods in your jar files that you loaded into the database.
          3c) The search order for customer-written routines is SQL standard: First we look in the jar file where the routine lives. Then we look in the other jar files in the order specified by SQLJ.ALTER_JAVA_PATH. Then we defer to the system class loader.
          3d) At runtime, when we invoke the routine, we make sure that it actually lives in the declared jar file.

          Show
          Rick Hillegas added a comment - Here's another crack at this: 1) The default behavior for Derby is the current behavior with all of its security holes for java routines. 2) To get secure behavior for java routines, the customer has to explicitly opt-in. Let's be vague about what that entails right now. 3) If you do opt-in, then you get the SQL standard behavior: 3a) Jar ids are mandatory. 3b) There is no SYS.ENV pseudo-jar. Instead, to access methods in the JRE you have to include little wrapper methods in your jar files that you loaded into the database. 3c) The search order for customer-written routines is SQL standard: First we look in the jar file where the routine lives. Then we look in the other jar files in the order specified by SQLJ.ALTER_JAVA_PATH. Then we defer to the system class loader. 3d) At runtime, when we invoke the routine, we make sure that it actually lives in the declared jar file.
          Hide
          Rick Hillegas added a comment -

          At this point, we are talking about an API which diverges from the SQL standard in several ways:

          A) Jar ids, which are mandatory in SQL, are optional for us.

          B) We have invented a pseudo-jar SYS.ENV, which does not appear in SQL.

          C) We cannot preserve the derby.database.classpath search order without breaking the rules for the jar-specific classpath set by SQLJ.ALTER_JAVA_PATH.

          I have two misgivings:

          1) I am worried that we will confuse both ourselves and our customers with an API which is neither the SQL standard nor the old, familiar Cloudscape API.

          2) I am worried that we have not stepped back and discussed the customer experience in terms of upgrade expectations and default, out-of-the-box behavior.

          Right now, I'd like to get some clarity on issue (2). Are we expecting any of the following:

          i) That Derby will be secure-by-default? Or is routine-security something you have to explicitly opt into?

          ii) That users upgrading to 10.3 won't have to change their applications?

          Show
          Rick Hillegas added a comment - At this point, we are talking about an API which diverges from the SQL standard in several ways: A) Jar ids, which are mandatory in SQL, are optional for us. B) We have invented a pseudo-jar SYS.ENV, which does not appear in SQL. C) We cannot preserve the derby.database.classpath search order without breaking the rules for the jar-specific classpath set by SQLJ.ALTER_JAVA_PATH. I have two misgivings: 1) I am worried that we will confuse both ourselves and our customers with an API which is neither the SQL standard nor the old, familiar Cloudscape API. 2) I am worried that we have not stepped back and discussed the customer experience in terms of upgrade expectations and default, out-of-the-box behavior. Right now, I'd like to get some clarity on issue (2). Are we expecting any of the following: i) That Derby will be secure-by-default? Or is routine-security something you have to explicitly opt into? ii) That users upgrading to 10.3 won't have to change their applications?
          Hide
          Rick Hillegas added a comment -

          > Derby already provides the extension to allow method names without a jar identifier. I don't think that functionality should be removed.

          If we allow this deviation from the standard, then, as you asked earlier, we will have to settle on a meaning for unqualified EXTERNAL NAMEs. To me, SYS.ENV seems like the best default here.

          Show
          Rick Hillegas added a comment - > Derby already provides the extension to allow method names without a jar identifier. I don't think that functionality should be removed. If we allow this deviation from the standard, then, as you asked earlier, we will have to settle on a meaning for unqualified EXTERNAL NAMEs. To me, SYS.ENV seems like the best default here.
          Hide
          Rick Hillegas added a comment -

          I think I have suggested the wrong search order. According to the "Enable database class loading with a property" section of the Derby Developer's Guide, SYS.ENV should be prefixed to the beginning of the classpath specified by ALTER_JAVA_PATH, not appended to the end.

          Show
          Rick Hillegas added a comment - I think I have suggested the wrong search order. According to the "Enable database class loading with a property" section of the Derby Developer's Guide, SYS.ENV should be prefixed to the beginning of the classpath specified by ALTER_JAVA_PATH, not appended to the end.
          Hide
          Daniel John Debrunner added a comment -

          > As I read the SQL standard, it seems to me that jar ids are mandatory parts of the EXTERNAL NAME. Without a jar id, you should get a syntax error when declaring a procedure/function.

          Derby already provides the extension to allow method names without a jar identifier. I don't think that functionality should be removed.

          Show
          Daniel John Debrunner added a comment - > As I read the SQL standard, it seems to me that jar ids are mandatory parts of the EXTERNAL NAME. Without a jar id, you should get a syntax error when declaring a procedure/function. Derby already provides the extension to allow method names without a jar identifier. I don't think that functionality should be removed.
          Hide
          Rick Hillegas added a comment -

          As I read the SQL standard, it seems to me that jar ids are mandatory parts of the EXTERNAL NAME. Without a jar id, you should get a syntax error when declaring a procedure/function. This, at least, is how I read sections 9.8 and 5.2 of part 13 of the SQL standard.

          I agree that if you allow someone to install a jar file, then you are implicitly allowing them to call any method in the JRE, the extensions jars, and the CLASSPATH.

          We could say that the only way to publish those methods is through wrappers in installed jar files. However, this seems a little awkward to me. In addition, I think it would raise upgrade issues for customers who have already published entry points in the JRE.

          I'm working on a spec now.

          Show
          Rick Hillegas added a comment - As I read the SQL standard, it seems to me that jar ids are mandatory parts of the EXTERNAL NAME. Without a jar id, you should get a syntax error when declaring a procedure/function. This, at least, is how I read sections 9.8 and 5.2 of part 13 of the SQL standard. I agree that if you allow someone to install a jar file, then you are implicitly allowing them to call any method in the JRE, the extensions jars, and the CLASSPATH. We could say that the only way to publish those methods is through wrappers in installed jar files. However, this seems a little awkward to me. In addition, I think it would raise upgrade issues for customers who have already published entry points in the JRE. I'm working on a spec now.
          Hide
          Daniel John Debrunner added a comment -

          "The only purpose of SYS.ENV is to qualify EXTERNAL NAMEs when declaring procedures and functions. "

          Does this mean that SYS.ENV would explicitly be needed as the jarid in EXTERNAL NAME?
          What about routines that are declared without a jar identifer?

          SYS.ENV looks a little forced as it doesn't behave like a regular jar file, I think due to merging the JRE and CLASSPATH classes which I think is the correct approach.

          In some cases it seems like EXECUTE permission on sqlj.install_jar would have the same functionality in terms of security as USAGE on SYS.ENV.

          I guess it will become clearer with a functional spec for DERBY-2252, the details of how SYS.ENV would work are not clear to me.

          Show
          Daniel John Debrunner added a comment - "The only purpose of SYS.ENV is to qualify EXTERNAL NAMEs when declaring procedures and functions. " Does this mean that SYS.ENV would explicitly be needed as the jarid in EXTERNAL NAME? What about routines that are declared without a jar identifer? SYS.ENV looks a little forced as it doesn't behave like a regular jar file, I think due to merging the JRE and CLASSPATH classes which I think is the correct approach. In some cases it seems like EXECUTE permission on sqlj.install_jar would have the same functionality in terms of security as USAGE on SYS.ENV. I guess it will become clearer with a functional spec for DERBY-2252 , the details of how SYS.ENV would work are not clear to me.
          Hide
          Rick Hillegas added a comment -

          I think that making this simpler is fine. I'm happy with one pseudo-jar which wraps everything loaded by the system, extensions, and bootstrap classloaders. As a nit, I'd sand down the name to something shorter. Maybe SYS.ENV.

          I would be comfortable with this usage:

          1) SYS.ENV is never mentioned in the jar-specific classpaths set by SQLJ.ALTER_JAVA_PATH. Instead, everything in SYS.ENV can be referenced, implicitly, by user code.

          2) The only purpose of SYS.ENV is to qualify EXTERNAL NAMEs when declaring procedures and functions.

          3) SYS.ENV starts out with USAGE granted to the database owner. Initially, only the database owner can publish entry points in SYS.ENV.

          Show
          Rick Hillegas added a comment - I think that making this simpler is fine. I'm happy with one pseudo-jar which wraps everything loaded by the system, extensions, and bootstrap classloaders. As a nit, I'd sand down the name to something shorter. Maybe SYS.ENV. I would be comfortable with this usage: 1) SYS.ENV is never mentioned in the jar-specific classpaths set by SQLJ.ALTER_JAVA_PATH. Instead, everything in SYS.ENV can be referenced, implicitly, by user code. 2) The only purpose of SYS.ENV is to qualify EXTERNAL NAMEs when declaring procedures and functions. 3) SYS.ENV starts out with USAGE granted to the database owner. Initially, only the database owner can publish entry points in SYS.ENV.
          Hide
          Kristian Waagan added a comment -

          You might already be aware of this, but you can change which classes are loaded by the bootstrap classloader by using one of the -Xbootclasspath options. In a trusted environment you can probably use the classloader == null check to determine if a class is a "JRE class", but in general any class can be a "JRE class".

          I also confirmed that both IBM and BEA VMs use null for the bootstrap classloader, but as Dan points out, I don't think this can be guaranteed. It also seems like these two vendors use the Sun application classloader (sun.misc.Launcher$AppClassLoader), but if it really is Sun's implementation I don't know.

          I think Dan's suggestion about combining the two categories of classes makes sense, if it goes well with the security model being worked out.

          Show
          Kristian Waagan added a comment - You might already be aware of this, but you can change which classes are loaded by the bootstrap classloader by using one of the -Xbootclasspath options. In a trusted environment you can probably use the classloader == null check to determine if a class is a "JRE class", but in general any class can be a "JRE class". I also confirmed that both IBM and BEA VMs use null for the bootstrap classloader, but as Dan points out, I don't think this can be guaranteed. It also seems like these two vendors use the Sun application classloader (sun.misc.Launcher$AppClassLoader), but if it really is Sun's implementation I don't know. I think Dan's suggestion about combining the two categories of classes makes sense, if it goes well with the security model being worked out.
          Hide
          Daniel John Debrunner added a comment -

          Maybe it's not worth making the split between classes provided by the JRE and those by the enviroment (CLASSPATH)?

          Maybe one pseudo jar: SYS.JRE_ENVIRONMENT ??

          Show
          Daniel John Debrunner added a comment - Maybe it's not worth making the split between classes provided by the JRE and those by the enviroment (CLASSPATH)? Maybe one pseudo jar: SYS.JRE_ENVIRONMENT ??
          Hide
          Daniel John Debrunner added a comment -

          Interesting ... I think it shows that the concept of System class is not what I thought, it's as you say classes from CLASSPATH.

          I don't think we can assume that null class loader means JRE class, that's explicit in the Java doc for Class.getClassLoader.
          Or at least if getClassLoader() returns null then it is the bootstraploader but you can't guarantee an implementation will use null for the bootstraploader.
          I'm pretty sure the IBM vms do not use null.

          The "Inside Java 2 Platform Security, Second Edition" makes the claim on page 43 that classes loaded by the bootstrap loader do have 'null' for a class loader. They base the claim on the "Dynamic Class Loading in the JavaTM Virtual Machine" paper, but I can't see any evidence in that paper, and that statement contradicts the javadoc.
          (the same page 43 also covers that "system classes" as defined by the JRE are really application classes)

          Show
          Daniel John Debrunner added a comment - Interesting ... I think it shows that the concept of System class is not what I thought, it's as you say classes from CLASSPATH. I don't think we can assume that null class loader means JRE class, that's explicit in the Java doc for Class.getClassLoader. Or at least if getClassLoader() returns null then it is the bootstraploader but you can't guarantee an implementation will use null for the bootstraploader. I'm pretty sure the IBM vms do not use null. The "Inside Java 2 Platform Security, Second Edition" makes the claim on page 43 that classes loaded by the bootstrap loader do have 'null' for a class loader. They base the claim on the "Dynamic Class Loading in the JavaTM Virtual Machine" paper, but I can't see any evidence in that paper, and that statement contradicts the javadoc. (the same page 43 also covers that "system classes" as defined by the JRE are really application classes)
          Hide
          Rick Hillegas added a comment -

          Thanks for those pointers. I have run a couple experiments on the Sun 1.4, 1.5, and 1.6 solaris vms. I get identical results on all vms. Here are those results:

          By default, I have three classloaders:

          1) A sun.misc.Launcher$AppClassLoader. This is the classloader returned by ClassLoader.getSystemClassLoader(). It is the ClassLoader which loads classes which I have written. I believe that this ClassLoader is responsible for classes visible on the CLASSPATH. I'm going to call this the System classloader.

          2) That ClassLoader has a parent, which is a sun.misc.Launcher$ExtClassLoader. This parent ClassLoader seems to be responsible for loading classes from jar files in jre/lib/ext. I'm going to call this the Extensions classloader.

          3) That ClassLoader has a null parent. I sampled some classes which appear in the javadoc for the Sun JREs. All of the the sampled classes have null as their ClassLoader. This includes classes in java., javax., org.w3c.dom.*, etc. I think that this null represents the JRE's ClassLoader.

          In trying to map this onto the concepts on the wiki page, I come up with something like the following:

          A) SYS.CLASSPATH embraces all classes whose ClassLoader is the System classloader. At a minimum.

          B) I don't know where to fit the classes loaded by the Extensions classloader.

          C) SYS.JRE could embrace all classes whose ClassLoader is null. I don't know whether the UR classloader is represented as null by other VM vendors. I also don't know if other vendors manage the same set of classes with their UR classloaders. I am worried about defining SYS.JRE as just the classes in java.*. I think that it would be prudent to respect the VM vendor's judgment about which classes cohere together under the UR classloader.

          Show
          Rick Hillegas added a comment - Thanks for those pointers. I have run a couple experiments on the Sun 1.4, 1.5, and 1.6 solaris vms. I get identical results on all vms. Here are those results: By default, I have three classloaders: 1) A sun.misc.Launcher$AppClassLoader. This is the classloader returned by ClassLoader.getSystemClassLoader(). It is the ClassLoader which loads classes which I have written. I believe that this ClassLoader is responsible for classes visible on the CLASSPATH. I'm going to call this the System classloader. 2) That ClassLoader has a parent, which is a sun.misc.Launcher$ExtClassLoader. This parent ClassLoader seems to be responsible for loading classes from jar files in jre/lib/ext. I'm going to call this the Extensions classloader. 3) That ClassLoader has a null parent. I sampled some classes which appear in the javadoc for the Sun JREs. All of the the sampled classes have null as their ClassLoader. This includes classes in java. , javax. , org.w3c.dom.*, etc. I think that this null represents the JRE's ClassLoader. In trying to map this onto the concepts on the wiki page, I come up with something like the following: A) SYS.CLASSPATH embraces all classes whose ClassLoader is the System classloader. At a minimum. B) I don't know where to fit the classes loaded by the Extensions classloader. C) SYS.JRE could embrace all classes whose ClassLoader is null. I don't know whether the UR classloader is represented as null by other VM vendors. I also don't know if other vendors manage the same set of classes with their UR classloaders. I am worried about defining SYS.JRE as just the classes in java.*. I think that it would be prudent to respect the VM vendor's judgment about which classes cohere together under the UR classloader.
          Hide
          Daniel John Debrunner added a comment -

          This paper (at the bottom of page 40) has some details on the loading of system classes and restrictions on user class loaders.
          "Dynamic Class Loading in the JavaTM Virtual Machine"
          http://www.cs.purdue.edu/homes/jv/smc/pubs/liang-oopsla98.pdf

          Reading that paper also made it obvious that the api's already treat system classes differently, e.g. 'ClassLoader.findSystemClass', thus SYS.JRE should probably map to the concept of system classes as defined by Java.

          Show
          Daniel John Debrunner added a comment - This paper (at the bottom of page 40) has some details on the loading of system classes and restrictions on user class loaders. "Dynamic Class Loading in the JavaTM Virtual Machine" http://www.cs.purdue.edu/homes/jv/smc/pubs/liang-oopsla98.pdf Reading that paper also made it obvious that the api's already treat system classes differently, e.g. 'ClassLoader.findSystemClass', thus SYS.JRE should probably map to the concept of system classes as defined by Java.
          Hide
          Daniel John Debrunner added a comment -

          SYS.JRE - Right, I was thinking about that this morning and it ities into the other thread about bootclasspath and the ability to tell if a class is on the bootclasspath. I think SYS.JRE really means any class on the boot class path, but currently the decision needs to be made before the class is loaded. That is decide to load from the jar classloader or delegate elsewhere. A possible alternative is to load any class using the default mechamism and then decide if it belongs to the JRE or not and make decisions off that.

          One more factor is seeing if the statement below has been extended to all classes defined in J2SE or continues to be just the java.* classes:

          "First, the ClassLoader will not attempt to load any classes in java.* packages from over the network. "

          http://java.sun.com/developer/onlineTraining/Security/Fundamentals/Security.html

          Possibly if the statement above continues to be true (limited to java.) and this is sufficient for security of the JVM then it's sufficient for Derby and SYS.JRE could just mean the java. classes.

          Show
          Daniel John Debrunner added a comment - SYS.JRE - Right, I was thinking about that this morning and it ities into the other thread about bootclasspath and the ability to tell if a class is on the bootclasspath. I think SYS.JRE really means any class on the boot class path, but currently the decision needs to be made before the class is loaded. That is decide to load from the jar classloader or delegate elsewhere. A possible alternative is to load any class using the default mechamism and then decide if it belongs to the JRE or not and make decisions off that. One more factor is seeing if the statement below has been extended to all classes defined in J2SE or continues to be just the java.* classes: "First, the ClassLoader will not attempt to load any classes in java.* packages from over the network. " http://java.sun.com/developer/onlineTraining/Security/Fundamentals/Security.html Possibly if the statement above continues to be true (limited to java. ) and this is sufficient for security of the JVM then it's sufficient for Derby and SYS.JRE could just mean the java. classes.
          Hide
          Rick Hillegas added a comment -

          The wiki page says that SYS.JRE includes just the classes in the java and javax namespaces. Some other namespaces ship with the JRE: org.ietf, org.omg, org.w3c, and org.xml. Should we include these in the namespaces covered by SYS.JRE?

          Show
          Rick Hillegas added a comment - The wiki page says that SYS.JRE includes just the classes in the java and javax namespaces. Some other namespaces ship with the JRE: org.ietf, org.omg, org.w3c, and org.xml. Should we include these in the namespaces covered by SYS.JRE?
          Hide
          Rick Hillegas added a comment -

          Thanks for the quick responses, Dan. I'd like to continue the discussion of "Setting derby.database.classpath" using the example you gave. Here's some more detail on the problem case I had in mind:

          o Suppose that there's an entry point Start_3() in the THREE jar file.

          o Suppose that Start_3() calls methods in class Next.

          o Suppose that there are three different versions of the Next class, one in each of the jar files.

          o Which version of the Next class gets picked up to resolve the references in Start_3()?

          It seems to me that the ANSI rules will give you the version of Next which lives in THREE. However, the Derby rules will give you the version in ONE.

          Show
          Rick Hillegas added a comment - Thanks for the quick responses, Dan. I'd like to continue the discussion of "Setting derby.database.classpath" using the example you gave. Here's some more detail on the problem case I had in mind: o Suppose that there's an entry point Start_3() in the THREE jar file. o Suppose that Start_3() calls methods in class Next. o Suppose that there are three different versions of the Next class, one in each of the jar files. o Which version of the Next class gets picked up to resolve the references in Start_3()? It seems to me that the ANSI rules will give you the version of Next which lives in THREE. However, the Derby rules will give you the version in ONE.
          Hide
          Daniel John Debrunner added a comment -

          > Rick Hillegas commented on DERBY-2206:
          > --------------------------------------
          >
          > I have some questions about the wiki page:

          Thanks for reading & providing feedback.

          > I think this analysis assumes that the engine is running under a SecurityManager with some Basic policy (defined elsewhere). So, for instance, user code is not allowed to create a custom classloader that can load classes from just about anywhere, including from the file which holds the jars installed into SYSFILES. Without this assumption, I think we may need to revisit some of the entries in the Referenced Classes sections. Maybe the Assumptions section could be pulled up to the top of the wiki page.

          I thought that the assumptions only applied to discussion that followed that section. Before the assumptions section it's definitions of how classes could be loaded, not which are possible. Maybe there needs to be another category of class defined, those from a class loader created by a referenced class.

          > "Resolving Classes -> 2nd Entry Point Class":
          >
          > I'm confused about why the Visibility is different for DBCP and SQLJAR. Wouldn't the USAGE privilege control the visibility of jar files stored in the database regardless of whether they appear on derby.database.classpath?

          If you mean the section when the routine has an EXTERNAL NAME with a jarid, then the database class path (DBCP) is not applicable. The class loading is defined by the SQL standard which only loads from the jar the entry point class is in and the classpath for that jar file (if set).

          > Following Referenced Classes section:
          >
          > This sentence ends abruptly: "The installed jar's optional classpath is."

          fixed

          >
          > "Setting derby.database.classpath":
          >
          > As I read section 4.3 of the SQL Standard, part 13, the order of resolution for classes referenced inside a loaded jar file looks like this:
          >
          > 1) First look for the class in that jar file
          > 2) Then look for the class in the JAVA_PATH bound to that jar file
          >
          > So the second bullet is true only if the jar file leads the list in derby.database.classpath.

          I don't see your logic here. If I have

          derby.database.classpath="ONE:TWO:THREE"

          then if my routine's entry point is in the THREE jar then referenced classes can be any class from ONE, TWO or THREE, which is as though the THREE jar had the classpath "ONE:TWO:THREE".

          So I can't see what is special about the first class specified in derby.database.classpath.

          Show
          Daniel John Debrunner added a comment - > Rick Hillegas commented on DERBY-2206 : > -------------------------------------- > > I have some questions about the wiki page: Thanks for reading & providing feedback. > I think this analysis assumes that the engine is running under a SecurityManager with some Basic policy (defined elsewhere). So, for instance, user code is not allowed to create a custom classloader that can load classes from just about anywhere, including from the file which holds the jars installed into SYSFILES. Without this assumption, I think we may need to revisit some of the entries in the Referenced Classes sections. Maybe the Assumptions section could be pulled up to the top of the wiki page. I thought that the assumptions only applied to discussion that followed that section. Before the assumptions section it's definitions of how classes could be loaded, not which are possible. Maybe there needs to be another category of class defined, those from a class loader created by a referenced class. > "Resolving Classes -> 2nd Entry Point Class": > > I'm confused about why the Visibility is different for DBCP and SQLJAR. Wouldn't the USAGE privilege control the visibility of jar files stored in the database regardless of whether they appear on derby.database.classpath? If you mean the section when the routine has an EXTERNAL NAME with a jarid, then the database class path (DBCP) is not applicable. The class loading is defined by the SQL standard which only loads from the jar the entry point class is in and the classpath for that jar file (if set). > Following Referenced Classes section: > > This sentence ends abruptly: "The installed jar's optional classpath is." fixed > > "Setting derby.database.classpath": > > As I read section 4.3 of the SQL Standard, part 13, the order of resolution for classes referenced inside a loaded jar file looks like this: > > 1) First look for the class in that jar file > 2) Then look for the class in the JAVA_PATH bound to that jar file > > So the second bullet is true only if the jar file leads the list in derby.database.classpath. I don't see your logic here. If I have derby.database.classpath="ONE:TWO:THREE" then if my routine's entry point is in the THREE jar then referenced classes can be any class from ONE, TWO or THREE, which is as though the THREE jar had the classpath "ONE:TWO:THREE". So I can't see what is special about the first class specified in derby.database.classpath.
          Hide
          Rick Hillegas added a comment -

          It appears to me that the wiki-described work could be staged as follows:

          1) Implement USAGE privilege. Require that USAGE be granted to PUBLIC on all jars in derby.database.classpath.

          2) Require jar ids in EXTERNAL NAME declarations. Introduce pseudo jars SYS.JRE and SYS.CLASSPATH

          3) Implement SQLJ.ALTER_JAVA_PATH

          Show
          Rick Hillegas added a comment - It appears to me that the wiki-described work could be staged as follows: 1) Implement USAGE privilege. Require that USAGE be granted to PUBLIC on all jars in derby.database.classpath. 2) Require jar ids in EXTERNAL NAME declarations. Introduce pseudo jars SYS.JRE and SYS.CLASSPATH 3) Implement SQLJ.ALTER_JAVA_PATH
          Hide
          Rick Hillegas added a comment -

          I have some questions about the wiki page:

          I think this analysis assumes that the engine is running under a SecurityManager with some Basic policy (defined elsewhere). So, for instance, user code is not allowed to create a custom classloader that can load classes from just about anywhere, including from the file which holds the jars installed into SYSFILES. Without this assumption, I think we may need to revisit some of the entries in the Referenced Classes sections. Maybe the Assumptions section could be pulled up to the top of the wiki page.

          "Resolving Classes -> 2nd Entry Point Class":

          I'm confused about why the Visibility is different for DBCP and SQLJAR. Wouldn't the USAGE privilege control the visibility of jar files stored in the database regardless of whether they appear on derby.database.classpath?

          Following Referenced Classes section:

          This sentence ends abruptly: "The installed jar's optional classpath is."

          "Setting derby.database.classpath":

          As I read section 4.3 of the SQL Standard, part 13, the order of resolution for classes referenced inside a loaded jar file looks like this:

          1) First look for the class in that jar file
          2) Then look for the class in the JAVA_PATH bound to that jar file

          So the second bullet is true only if the jar file leads the list in derby.database.classpath.

          Show
          Rick Hillegas added a comment - I have some questions about the wiki page: I think this analysis assumes that the engine is running under a SecurityManager with some Basic policy (defined elsewhere). So, for instance, user code is not allowed to create a custom classloader that can load classes from just about anywhere, including from the file which holds the jars installed into SYSFILES. Without this assumption, I think we may need to revisit some of the entries in the Referenced Classes sections. Maybe the Assumptions section could be pulled up to the top of the wiki page. "Resolving Classes -> 2nd Entry Point Class": I'm confused about why the Visibility is different for DBCP and SQLJAR. Wouldn't the USAGE privilege control the visibility of jar files stored in the database regardless of whether they appear on derby.database.classpath? Following Referenced Classes section: This sentence ends abruptly: "The installed jar's optional classpath is." "Setting derby.database.classpath": As I read section 4.3 of the SQL Standard, part 13, the order of resolution for classes referenced inside a loaded jar file looks like this: 1) First look for the class in that jar file 2) Then look for the class in the JAVA_PATH bound to that jar file So the second bullet is true only if the jar file leads the list in derby.database.classpath.
          Hide
          Rick Hillegas added a comment -

          Clarified the bug summary line.

          Show
          Rick Hillegas added a comment - Clarified the bug summary line.

            People

            • Assignee:
              Unassigned
              Reporter:
              Rick Hillegas
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development