Derby
  1. Derby
  2. DERBY-4191

Lack of SELECT privilege does not prevent SELECT COUNT(*)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.4.2.0, 10.5.1.1
    • Fix Version/s: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.1.0
    • Component/s: SQL
    • Labels:
      None
    • Urgency:
      Normal
    • Issue & fix info:
      Release Note Needed
    • Bug behavior facts:
      Security, Wrong query result

      Description

      A user that does not have SELECT privilege on a table can still perform a SELECT COUNT on that table. Counting a specific column (e.g., SELECT COUNT(X)) is prevented.

      1. DERBY4191_ColumnLevelCheckInStatmentColumnPerm_diff_patch2.txt
        20 kB
        Mamta A. Satoor
      2. DERBY4191_ColumnLevelCheckInStatmentColumnPerm_stat_patch2.txt
        0.7 kB
        Mamta A. Satoor
      3. DERBY4191_ColumnLevelCheckInStatmentTablePerm_diff_patch1.txt
        20 kB
        Mamta A. Satoor
      4. DERBY4191_countStar_privilege_diff_patch1.txt
        11 kB
        Mamta A. Satoor
      5. DERBY4191_miniumSelectPriv_CursorNode_And_Subquery_diff_patch6.txt
        34 kB
        Mamta A. Satoor
      6. DERBY4191_miniumSelectPriv_CursorNode_And_Subquery_stat_patch6.txt
        0.7 kB
        Mamta A. Satoor
      7. DERBY4191_miniumSelectPrivOnAllTables_And_Subquery_diff_patch5.txt
        34 kB
        Mamta A. Satoor
      8. DERBY4191_miniumSelectPrivOnAllTables_And_Subquery_stat_patch5.txt
        0.8 kB
        Mamta A. Satoor
      9. DERBY4191_miniumSelectPrivOnAllTables_diff_patch3.txt
        24 kB
        Mamta A. Satoor
      10. DERBY4191_miniumSelectPrivOnAllTables_diff_patch4.txt
        25 kB
        Mamta A. Satoor
      11. DERBY4191_miniumSelectPrivOnAllTables_stat_patch3.txt
        0.7 kB
        Mamta A. Satoor
      12. DERBY4191_miniumSelectPrivOnAllTables_stat_patch4.txt
        0.8 kB
        Mamta A. Satoor
      13. releaseNote.html
        4 kB
        Rick Hillegas
      14. releaseNote.html
        3 kB
        Mamta A. Satoor
      15. repro.sql
        0.2 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          Attached is a repro script showing that count is disallowed and count is allowed for a non-privileged user.

          $ java -Dderby.database.sqlAuthorization=true -jar lib/derbyrun.jar ij repro.sql
          ij version 10.5
          ij> connect 'jdbc:derby:db;user=root;create=true';
          WARNING 01J14: SQL authorization is being used without first enabling authentication.
          ij> create table t (x int);
          0 rows inserted/updated/deleted
          ij> insert into t values 1,2,3;
          3 rows inserted/updated/deleted
          ij> connect 'jdbc:derby:db;user=kah';
          WARNING 01J14: SQL authorization is being used without first enabling authentication.
          ij(CONNECTION1)> select count from root.t;
          ERROR 42502: User 'KAH' does not have SELECT permission on column 'X' of table 'ROOT'.'T'.
          ij(CONNECTION1)> select count from root.t;
          1
          -----------
          3

          1 row selected
          ij(CONNECTION1)>

          Show
          Knut Anders Hatlen added a comment - Attached is a repro script showing that count is disallowed and count is allowed for a non-privileged user. $ java -Dderby.database.sqlAuthorization=true -jar lib/derbyrun.jar ij repro.sql ij version 10.5 ij> connect 'jdbc:derby:db;user=root;create=true'; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij> create table t (x int); 0 rows inserted/updated/deleted ij> insert into t values 1,2,3; 3 rows inserted/updated/deleted ij> connect 'jdbc:derby:db;user=kah'; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(CONNECTION1)> select count from root.t; ERROR 42502: User 'KAH' does not have SELECT permission on column 'X' of table 'ROOT'.'T'. ij(CONNECTION1)> select count from root.t; 1 ----------- 3 1 row selected ij(CONNECTION1)>
          Hide
          Rick Hillegas added a comment -

          Triaged July 2, 2009: Checked Security and WrongQueryResult boxes. Assiged normal urgency.

          Show
          Rick Hillegas added a comment - Triaged July 2, 2009: Checked Security and WrongQueryResult boxes. Assiged normal urgency.
          Hide
          Rick Hillegas added a comment -

          Before fixing this bug, we need to decide what privileges are needed to execute the following statement:

          select count from t

          I believe that all you need is SELECT privilege on some column of the table. That at least is the minimum set of privileges required by the SQL Standard, part 2, section 7.6 <table reference>, access rule 1.ii.1.B. I asked the SQL committee for its opinion and got one response, which concurred:

          "There are no access rules for count (in either 6.9 <set function specification> or
          10.9 <aggregate function>), nor in 7.12 <query specification> or
          7.13 <query expression>, so that leaves just the access rules for t in
          7.6 <table reference>. I think you are right."

          Show
          Rick Hillegas added a comment - Before fixing this bug, we need to decide what privileges are needed to execute the following statement: select count from t I believe that all you need is SELECT privilege on some column of the table. That at least is the minimum set of privileges required by the SQL Standard, part 2, section 7.6 <table reference>, access rule 1.ii.1.B. I asked the SQL committee for its opinion and got one response, which concurred: "There are no access rules for count (in either 6.9 <set function specification> or 10.9 <aggregate function>), nor in 7.12 <query specification> or 7.13 <query expression>, so that leaves just the access rules for t in 7.6 <table reference>. I think you are right."
          Hide
          Rick Hillegas added a comment -

          The solution to this bug should also insist on the same privileges for the following query:

          select count(1) from t;

          Show
          Rick Hillegas added a comment - The solution to this bug should also insist on the same privileges for the following query: select count(1) from t;
          Hide
          Mamta A. Satoor added a comment -

          Thanks for your comment on this jira, Rick. I was starting to look at the jira and was thinking about what privileges would be required.

          It seems like Derby has a SELECT level privilege for the table (I think that gets used for instance when somebody attempts to lock the table) and I thought that is what would be required for count or count(1). But it seems like SQL-spec is saying that SELECT privilege on any column of the table is enough. I think that does make sense because a user can easily get count equivalent by going count(columnwithselectprivilege) and hence it should be fine to have select privilege on any column to do count or count(1) equivalent.

          Show
          Mamta A. Satoor added a comment - Thanks for your comment on this jira, Rick. I was starting to look at the jira and was thinking about what privileges would be required. It seems like Derby has a SELECT level privilege for the table (I think that gets used for instance when somebody attempts to lock the table) and I thought that is what would be required for count or count(1). But it seems like SQL-spec is saying that SELECT privilege on any column of the table is enough. I think that does make sense because a user can easily get count equivalent by going count(columnwithselectprivilege) and hence it should be fine to have select privilege on any column to do count or count(1) equivalent.
          Hide
          Rick Hillegas added a comment -

          Hi Mamta,

          Thanks for volunteering to look at this issue. Off the top of my head, I think that the tricky bit may be that privilege checks are currently modelled as an ANDed list of required permissions. What is needed here seems to be an ORed list of permissions. Thanks.

          Show
          Rick Hillegas added a comment - Hi Mamta, Thanks for volunteering to look at this issue. Off the top of my head, I think that the tricky bit may be that privilege checks are currently modelled as an ANDed list of required permissions. What is needed here seems to be an ORed list of permissions. Thanks.
          Hide
          Mamta A. Satoor added a comment -

          Currently, we have a method called getRequiredPermissionsList() in CompilerContext. I am thinking of adding another method called getRequiredPermissionsListForCountStar() (let me know if some other name suggestion people may have). This list will just include the TableDescriptors of tables involved in count or count(1) kind of variations. And for these TableDescriptors, we will check if there is SELECT privilege available on table level OR at any column level.

          Show
          Mamta A. Satoor added a comment - Currently, we have a method called getRequiredPermissionsList() in CompilerContext. I am thinking of adding another method called getRequiredPermissionsListForCountStar() (let me know if some other name suggestion people may have). This list will just include the TableDescriptors of tables involved in count or count(1) kind of variations. And for these TableDescriptors, we will check if there is SELECT privilege available on table level OR at any column level.
          Hide
          Rick Hillegas added a comment -

          Hi Mamta,

          Without seeing how the method is used it is hard to comment. However, I think you are trying to capture the sense of "The absolutely minimal set of permissions needed to SELECT from a table." That is my sense of what is meant by part 2, section 7.6 <table reference>, access rule 1.ii.1.B. So a better name for your proposed method may be getMinimalSelectPermissionsList().

          Another way to tackle this might be to invent a new kind of permission which can't be granted but which can be used internally: a MINIMAL_SELECT_PRIVILEGE for tables. This solution would look something like the following:

          o At bind time, you would add a MINIMAL_SELECT_PRIVILEGE( T ) to the list of required table privileges for every table T that is selected from.

          o For extra credit, this privilege could be removed from the list for any table which has other required SELECT privileges. That removal might happen during bind() or maybe during code generation. Alternatively, you could wait till execution time to short-circuit the check for this privilege.

          o At execution time, you would then do what I think you're planning on: If you see a MINIMAL_SELECT_PRIVILEGE required for a table, you would check whether the user/currentRole enjoys a table-wide SELECT privilege or SELECT privilege on at least one column.

          Thanks,
          -Rick

          Show
          Rick Hillegas added a comment - Hi Mamta, Without seeing how the method is used it is hard to comment. However, I think you are trying to capture the sense of "The absolutely minimal set of permissions needed to SELECT from a table." That is my sense of what is meant by part 2, section 7.6 <table reference>, access rule 1.ii.1.B. So a better name for your proposed method may be getMinimalSelectPermissionsList(). Another way to tackle this might be to invent a new kind of permission which can't be granted but which can be used internally: a MINIMAL_SELECT_PRIVILEGE for tables. This solution would look something like the following: o At bind time, you would add a MINIMAL_SELECT_PRIVILEGE( T ) to the list of required table privileges for every table T that is selected from. o For extra credit, this privilege could be removed from the list for any table which has other required SELECT privileges. That removal might happen during bind() or maybe during code generation. Alternatively, you could wait till execution time to short-circuit the check for this privilege. o At execution time, you would then do what I think you're planning on: If you see a MINIMAL_SELECT_PRIVILEGE required for a table, you would check whether the user/currentRole enjoys a table-wide SELECT privilege or SELECT privilege on at least one column. Thanks, -Rick
          Hide
          Mamta A. Satoor added a comment -

          Rick, I really appreciate you taking the time on thinking about this jira. As a start, I am thinking I will go ahead and work on getMinimalSelectPermissionsList/getRequiredPermissionsListForCountStar() approach. I think the actual implementation of that method will be required even by the alternative approach you suggested. So, for now, I will work on implementing the new method and have it used for count case. Once I have that working, we can see if we should add a new internal privilege type MINIMAL_SELECT_PRIVILEGE and use that privilege type rather than internal method calls to implement the final solution. Once I have some kind of code ready, I will post it to this jira so we are more clear on what I am proposing to do. Thanks.

          Show
          Mamta A. Satoor added a comment - Rick, I really appreciate you taking the time on thinking about this jira. As a start, I am thinking I will go ahead and work on getMinimalSelectPermissionsList/getRequiredPermissionsListForCountStar() approach. I think the actual implementation of that method will be required even by the alternative approach you suggested. So, for now, I will work on implementing the new method and have it used for count case. Once I have that working, we can see if we should add a new internal privilege type MINIMAL_SELECT_PRIVILEGE and use that privilege type rather than internal method calls to implement the final solution. Once I have some kind of code ready, I will post it to this jira so we are more clear on what I am proposing to do. Thanks.
          Hide
          Knut Anders Hatlen added a comment -

          Just to add to Rick's point, this problem is not limited to COUNT, or to aggregate functions. Same problem can be seen with for instance this statement that just selects a constant expression from table ROOT.T (executed as user KAH in the original repro):

          ij(CONNECTION1)> select x from root.t;
          ERROR 42502: User 'KAH' does not have SELECT permission on column 'X' of table 'ROOT'.'T'.
          ij(CONNECTION1)> select 1 from root.t;
          1
          -----------
          1
          1
          1

          3 rows selected

          Show
          Knut Anders Hatlen added a comment - Just to add to Rick's point, this problem is not limited to COUNT, or to aggregate functions. Same problem can be seen with for instance this statement that just selects a constant expression from table ROOT.T (executed as user KAH in the original repro): ij(CONNECTION1)> select x from root.t; ERROR 42502: User 'KAH' does not have SELECT permission on column 'X' of table 'ROOT'.'T'. ij(CONNECTION1)> select 1 from root.t; 1 ----------- 1 1 1 3 rows selected
          Hide
          Mamta A. Satoor added a comment -

          I am attaching a patch(DERBY4191_ColumnLevelCheckInStatmentTablePerm_diff_patch1.txt) which resolves this jira's issue(the patch is not ready for commit yet).

          I have piggybacked on first and third bullet items of Rick's suggestion. At this point, I am not planning on optimizing the code by checking if there is already a SELECT privilege requirement on table or a column in the table, and if yes, then drop the MINIMAL_SELECT_PRIVILEGE requirement on that same table.

          The logic is as follows. At the bind time, The compile time changes went into SelectNode and AggregateNode to see if we need to add MINIMAL_SELECT_PRIVILEGE requirement.
          a)I check in the SelectNode if all the columns in the select list are constants. If yes, then I add MINIMAL_SELECT_PRIVILEGE requirement for all the tables involved in the select. A new method was added for doing the column constant check. That method went in ResultColumnList.java
          b)In the AggregateNode, I check if the aggregate is of the kind count or count(constant), then we should require MINIMAL_SELECT_PRIVILEGE for all the tables involved in the select.
          c)Then at execute time, in StatementTablePermission, if I don't find a table level select privilege, then I check if there is atleast one column level select privilege if we are working with MINIMAL_SELECT_PRIVILEGE requirement. For this, I had to add a new method, called checkForAtleastOneSelectColumnPrivilege. The majority of this code is copied from StatementColumnPermission and this the reason I don't want this patch to be committed yet. I want to see if I can change the MINIMAL_SELECT_PRIVILEGE requirement to be at the column level rather than table level. That way, I might be able to use the existing code in StatementColumnPermission rather than copying majority of it in StatementTablePermission as a new method.
          d)I have added new tests to RolesConferredPrivilegesTest and GrantRevokeDDLTest.
          e)As a next step, I want to focus on utilizing most of existing code in StatementColumnPermission. Once I have that ready, I will post another patch. I will appreciate though if someone can review the patch and the logic to see if I may have missed anything.

          The files impacted by the change are as follows
          svn stat -q
          M java\engine\org\apache\derby\impl\sql\compile\SelectNode.java
          M java\engine\org\apache\derby\impl\sql\compile\AggregateNode.java
          M java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
          M java\engine\org\apache\derby\impl\sql\catalog\DataDictionaryImpl.java
          M java\engine\org\apache\derby\iapi\sql\conn\Authorizer.java
          M java\engine\org\apache\derby\iapi\sql\dictionary\StatementTablePermission.java
          M java\testing\org\apache\derbyTesting\functionTests\tests\lang\RolesConferredPrivilegesTest.java
          M java\testing\org\apache\derbyTesting\functionTests\tests\lang\GrantRevokeDDLTest.java

          I ran all the tests and ran into following failure. I do not think it is related to my changes but not sure why this error is showing up. I can consistently reproduce this eror. There was reference to this kind of failure once on derby-dev list with thread titled "[jira] Issue Comment Edited: (DERBY-3451) Remove dependency between StandardException class and org.apache.derby.impl.jdbc classes". I do not think there was any resolution to that failure.
          There were 2 failures:
          1) CheckToursDBTest:embeddedjunit.framework.AssertionFailedError: org/apache/derbyTesting/functionTests/tests/demo/cupisle.gif
          at org.apache.derbyTesting.junit.SupportFilesSetup.copyFiles(SupportFilesSetup.java:174)
          at org.apache.derbyTesting.junit.SupportFilesSetup.access$000(SupportFilesSetup.java:64)
          at org.apache.derbyTesting.junit.SupportFilesSetup$1.run(SupportFilesSetup.java:139)
          at java.security.AccessController.doPrivileged(AccessController.java:251)
          at org.apache.derbyTesting.junit.SupportFilesSetup.privCopyFiles(SupportFilesSetup.java:135)
          at org.apache.derbyTesting.junit.SupportFilesSetup.setUp(SupportFilesSetup.java:120)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          2) CheckToursDBTest:clientjunit.framework.AssertionFailedError: org/apache/derbyTesting/functionTests/tests/demo/cupisle.gif
          at org.apache.derbyTesting.junit.SupportFilesSetup.copyFiles(SupportFilesSetup.java:174)
          at org.apache.derbyTesting.junit.SupportFilesSetup.access$000(SupportFilesSetup.java:64)
          at org.apache.derbyTesting.junit.SupportFilesSetup$1.run(SupportFilesSetup.java:139)
          at java.security.AccessController.doPrivileged(AccessController.java:251)
          at rg.apache.derbyTesting.junit.SupportFilesSetup.privCopyFiles (SupportFilesSetup.java:135)
          at org.apache.derbyTesting.junit.SupportFilesSetup.setUp(SupportFilesSetup.java:120)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)

          Show
          Mamta A. Satoor added a comment - I am attaching a patch(DERBY4191_ColumnLevelCheckInStatmentTablePerm_diff_patch1.txt) which resolves this jira's issue(the patch is not ready for commit yet). I have piggybacked on first and third bullet items of Rick's suggestion. At this point, I am not planning on optimizing the code by checking if there is already a SELECT privilege requirement on table or a column in the table, and if yes, then drop the MINIMAL_SELECT_PRIVILEGE requirement on that same table. The logic is as follows. At the bind time, The compile time changes went into SelectNode and AggregateNode to see if we need to add MINIMAL_SELECT_PRIVILEGE requirement. a)I check in the SelectNode if all the columns in the select list are constants. If yes, then I add MINIMAL_SELECT_PRIVILEGE requirement for all the tables involved in the select. A new method was added for doing the column constant check. That method went in ResultColumnList.java b)In the AggregateNode, I check if the aggregate is of the kind count or count(constant), then we should require MINIMAL_SELECT_PRIVILEGE for all the tables involved in the select. c)Then at execute time, in StatementTablePermission, if I don't find a table level select privilege, then I check if there is atleast one column level select privilege if we are working with MINIMAL_SELECT_PRIVILEGE requirement. For this, I had to add a new method, called checkForAtleastOneSelectColumnPrivilege. The majority of this code is copied from StatementColumnPermission and this the reason I don't want this patch to be committed yet. I want to see if I can change the MINIMAL_SELECT_PRIVILEGE requirement to be at the column level rather than table level. That way, I might be able to use the existing code in StatementColumnPermission rather than copying majority of it in StatementTablePermission as a new method. d)I have added new tests to RolesConferredPrivilegesTest and GrantRevokeDDLTest. e)As a next step, I want to focus on utilizing most of existing code in StatementColumnPermission. Once I have that ready, I will post another patch. I will appreciate though if someone can review the patch and the logic to see if I may have missed anything. The files impacted by the change are as follows svn stat -q M java\engine\org\apache\derby\impl\sql\compile\SelectNode.java M java\engine\org\apache\derby\impl\sql\compile\AggregateNode.java M java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java M java\engine\org\apache\derby\impl\sql\catalog\DataDictionaryImpl.java M java\engine\org\apache\derby\iapi\sql\conn\Authorizer.java M java\engine\org\apache\derby\iapi\sql\dictionary\StatementTablePermission.java M java\testing\org\apache\derbyTesting\functionTests\tests\lang\RolesConferredPrivilegesTest.java M java\testing\org\apache\derbyTesting\functionTests\tests\lang\GrantRevokeDDLTest.java I ran all the tests and ran into following failure. I do not think it is related to my changes but not sure why this error is showing up. I can consistently reproduce this eror. There was reference to this kind of failure once on derby-dev list with thread titled " [jira] Issue Comment Edited: ( DERBY-3451 ) Remove dependency between StandardException class and org.apache.derby.impl.jdbc classes". I do not think there was any resolution to that failure. There were 2 failures: 1) CheckToursDBTest:embeddedjunit.framework.AssertionFailedError: org/apache/derbyTesting/functionTests/tests/demo/cupisle.gif at org.apache.derbyTesting.junit.SupportFilesSetup.copyFiles(SupportFilesSetup.java:174) at org.apache.derbyTesting.junit.SupportFilesSetup.access$000(SupportFilesSetup.java:64) at org.apache.derbyTesting.junit.SupportFilesSetup$1.run(SupportFilesSetup.java:139) at java.security.AccessController.doPrivileged(AccessController.java:251) at org.apache.derbyTesting.junit.SupportFilesSetup.privCopyFiles(SupportFilesSetup.java:135) at org.apache.derbyTesting.junit.SupportFilesSetup.setUp(SupportFilesSetup.java:120) at junit.extensions.TestSetup$1.protect(TestSetup.java:18) at junit.extensions.TestSetup.run(TestSetup.java:23) 2) CheckToursDBTest:clientjunit.framework.AssertionFailedError: org/apache/derbyTesting/functionTests/tests/demo/cupisle.gif at org.apache.derbyTesting.junit.SupportFilesSetup.copyFiles(SupportFilesSetup.java:174) at org.apache.derbyTesting.junit.SupportFilesSetup.access$000(SupportFilesSetup.java:64) at org.apache.derbyTesting.junit.SupportFilesSetup$1.run(SupportFilesSetup.java:139) at java.security.AccessController.doPrivileged(AccessController.java:251) at rg.apache.derbyTesting.junit.SupportFilesSetup.privCopyFiles (SupportFilesSetup.java:135) at org.apache.derbyTesting.junit.SupportFilesSetup.setUp(SupportFilesSetup.java:120) at junit.extensions.TestSetup$1.protect(TestSetup.java:18) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23)
          Hide
          Rick Hillegas added a comment -

          Thanks for the patch, Mamta. I think that this would be good, incremental improvement. My chief misgiving about this patch is that it attempts to enumerate the cases which could go wrong. I don't think that I am smart enough to list the problem cases even with the limited grammar that we have now. As we extend the language, more problem cases may creep in. Here for instance is a query which should fail but which still succeeds with this patch:

          select myTable.a from myTable, admin.privateTable; – here admin.privateTable is a table that I don't have any SELECT privileges on

          I continue to think that it would be best to always add the MIN_SELECT_PRIV and then weed it out later if you can prove that it isn't needed. I think the downside of this alternative approach is that some cases may slip through where we needlessly look for column permissions. On the whole, I think that is a better problem to have than ignoring permissions checks when they are required.

          Another small comment: The code which adds the MIN_SELECT_PRIV seems to be duplicated in a couple files. I would recommend abstracting this code into a shared subroutine.

          Thanks!

          Show
          Rick Hillegas added a comment - Thanks for the patch, Mamta. I think that this would be good, incremental improvement. My chief misgiving about this patch is that it attempts to enumerate the cases which could go wrong. I don't think that I am smart enough to list the problem cases even with the limited grammar that we have now. As we extend the language, more problem cases may creep in. Here for instance is a query which should fail but which still succeeds with this patch: select myTable.a from myTable, admin.privateTable; – here admin.privateTable is a table that I don't have any SELECT privileges on I continue to think that it would be best to always add the MIN_SELECT_PRIV and then weed it out later if you can prove that it isn't needed. I think the downside of this alternative approach is that some cases may slip through where we needlessly look for column permissions. On the whole, I think that is a better problem to have than ignoring permissions checks when they are required. Another small comment: The code which adds the MIN_SELECT_PRIV seems to be duplicated in a couple files. I would recommend abstracting this code into a shared subroutine. Thanks!
          Hide
          Mamta A. Satoor added a comment -

          I am attaching a patch (DERBY4191_ColumnLevelCheckInStatmentColumnPerm_diff_patch2.txt) is same as the previous patch EXCEPT that the minimum select privilege requirement is enforced in StatementColumnPermission rather than StatementTablePermission thus eliminating the need to duplicate the code.

          I ran derbyall and junit tests and even with this patch, I continue to get the failure CheckToursDBTest:embeddedjunit.framework.AssertionFailedError: org/apache/derbyTesting/functionTests/tests/demo/cupisle.gif
          In addition, I got one more failure, testReplication_Encrypted_1_miniLoad_negative(org.apache.derbyTesting.functio
          nTests.tests.replicationTests.ReplicationRun_Local_Encrypted_1)junit.framework.ComparisonFailure: Unexpected SQL state. expected:<...0> but was:<...1>

          I reran the replication suite and didn't get the above failure when running this way.
          $ java -Dderby.tests.trace=true -Xmx256M -XX:MaxPermSize=128M junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.replicationTests.Replication.Suite

          If anyone has cycles at all, if they can run the junit suite with the patch I am attaching, I will appreciate it. I want to be sure that nothing in my changes has broken the 2 failures I am seeing(may be they are specific to my computer).

          Rick, thanks for reviwing my earlier patch. I agree with your comments about not trying to selective handle specific select queries. As a next step, I will work on your suggestion of requiring minimum select privilege on all the tables in the select query rather than trying to handpick the ones based on select constant or select count or select count(constant) because this approach does not cover a query like select t1.c1 from anotheruser.t1, anotheruser.t2

          I will post that patch once it is ready.

          Show
          Mamta A. Satoor added a comment - I am attaching a patch (DERBY4191_ColumnLevelCheckInStatmentColumnPerm_diff_patch2.txt) is same as the previous patch EXCEPT that the minimum select privilege requirement is enforced in StatementColumnPermission rather than StatementTablePermission thus eliminating the need to duplicate the code. I ran derbyall and junit tests and even with this patch, I continue to get the failure CheckToursDBTest:embeddedjunit.framework.AssertionFailedError: org/apache/derbyTesting/functionTests/tests/demo/cupisle.gif In addition, I got one more failure, testReplication_Encrypted_1_miniLoad_negative(org.apache.derbyTesting.functio nTests.tests.replicationTests.ReplicationRun_Local_Encrypted_1)junit.framework.ComparisonFailure: Unexpected SQL state. expected:<...0> but was:<...1> I reran the replication suite and didn't get the above failure when running this way. $ java -Dderby.tests.trace=true -Xmx256M -XX:MaxPermSize=128M junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.replicationTests.Replication.Suite If anyone has cycles at all, if they can run the junit suite with the patch I am attaching, I will appreciate it. I want to be sure that nothing in my changes has broken the 2 failures I am seeing(may be they are specific to my computer). Rick, thanks for reviwing my earlier patch. I agree with your comments about not trying to selective handle specific select queries. As a next step, I will work on your suggestion of requiring minimum select privilege on all the tables in the select query rather than trying to handpick the ones based on select constant or select count or select count(constant) because this approach does not cover a query like select t1.c1 from anotheruser.t1, anotheruser.t2 I will post that patch once it is ready.
          Hide
          Mamta A. Satoor added a comment -

          I am attaching a new patch (DERBY4191_miniumSelectPrivOnAllTables_diff_patch3.txt) which now adds a minimum select privilege requirement for all the tables in a SELECT query and if such a requirement is already getting satisfied with already existing select privilege requirement on the table(s), then we will not add the redundant minimum select privilege requirement. eg
          select c1 from t1
          For the query above, we do not require a minimum select privilege on t1 because we have already select privilege requirement on t1.c1
          Now consider the following query
          select 1 from t1
          For the query above, we DO want to add a minumum select privilege on t1 because there is no other select privilege requirement on table t1 or any of it's columns.

          The code had to be intelligent enough to not require minimum select privilege for following query
          update t1 set c1=1
          for this query, we have a SelectNode which provides the resultset for update. But for this SelectNode, we do not want any minimum select privileges on t1. Code for recognizing such a query is added into SelectNode.

          I have run all the junit and derbyall tests and only ran into known jira issue DERBY-4463. Prior run of junit with the patch gave me some upgrade test failures which I occassionally run into on my machine and I do not think those upgrade test failures are related to my patch. I will greatly appreciate if someone can run the junit tests for me with the patch to make sure they run fine.

          Please let me know if anyone has any feedback on the patch. I will plan on committing it early next week. Thanks

          Show
          Mamta A. Satoor added a comment - I am attaching a new patch (DERBY4191_miniumSelectPrivOnAllTables_diff_patch3.txt) which now adds a minimum select privilege requirement for all the tables in a SELECT query and if such a requirement is already getting satisfied with already existing select privilege requirement on the table(s), then we will not add the redundant minimum select privilege requirement. eg select c1 from t1 For the query above, we do not require a minimum select privilege on t1 because we have already select privilege requirement on t1.c1 Now consider the following query select 1 from t1 For the query above, we DO want to add a minumum select privilege on t1 because there is no other select privilege requirement on table t1 or any of it's columns. The code had to be intelligent enough to not require minimum select privilege for following query update t1 set c1=1 for this query, we have a SelectNode which provides the resultset for update. But for this SelectNode, we do not want any minimum select privileges on t1. Code for recognizing such a query is added into SelectNode. I have run all the junit and derbyall tests and only ran into known jira issue DERBY-4463 . Prior run of junit with the patch gave me some upgrade test failures which I occassionally run into on my machine and I do not think those upgrade test failures are related to my patch. I will greatly appreciate if someone can run the junit tests for me with the patch to make sure they run fine. Please let me know if anyone has any feedback on the patch. I will plan on committing it early next week. Thanks
          Hide
          Rick Hillegas added a comment -

          Thanks for the new patch, Mamta. I think this is moving in the right direction. I have a couple comments:

          1) It's hard to tell whether the new tests cover the cases where permissions come from roles rather than from direct grants. It would be good to write some tests for those cases.

          2) After applying this patch, the following query succeeds if the user has update privilege on the table but not select privilege. I believe that this query should fail because the user does not have select privilege:

          update admin.t set a = ( select max(a) + 2 from admin.t );

          Here is a full script which shows this problem:

          connect 'jdbc:derby:memory:dummy;create=true;user=admin;password=adminpassword';

          create table t( a int, b int );

          insert into t( a, b ) values ( 1, 1 );
          call syscs_util.syscs_set_database_property( 'derby.database.sqlAuthorization', 'true' );

          connect 'jdbc:derby:memory:dummy;shutdown=true;user=admin;password=adminpassword';

          connect 'jdbc:derby:memory:dummy;user=admin;password=adminpassword';

          grant update on t to public;

          connect 'jdbc:derby:memory:dummy;user=ruth;password=ruthpassword';

          – fails
          select * from admin.t;

          update admin.t set a = 2;

          – succeeds but should not
          update admin.t set a = ( select max(a) + 2 from admin.t );

          Show
          Rick Hillegas added a comment - Thanks for the new patch, Mamta. I think this is moving in the right direction. I have a couple comments: 1) It's hard to tell whether the new tests cover the cases where permissions come from roles rather than from direct grants. It would be good to write some tests for those cases. 2) After applying this patch, the following query succeeds if the user has update privilege on the table but not select privilege. I believe that this query should fail because the user does not have select privilege: update admin.t set a = ( select max(a) + 2 from admin.t ); Here is a full script which shows this problem: connect 'jdbc:derby:memory:dummy;create=true;user=admin;password=adminpassword'; create table t( a int, b int ); insert into t( a, b ) values ( 1, 1 ); call syscs_util.syscs_set_database_property( 'derby.database.sqlAuthorization', 'true' ); connect 'jdbc:derby:memory:dummy;shutdown=true;user=admin;password=adminpassword'; connect 'jdbc:derby:memory:dummy;user=admin;password=adminpassword'; grant update on t to public; connect 'jdbc:derby:memory:dummy;user=ruth;password=ruthpassword'; – fails select * from admin.t; update admin.t set a = 2; – succeeds but should not update admin.t set a = ( select max(a) + 2 from admin.t );
          Hide
          Mamta A. Satoor added a comment -

          Rick, thanks for reviewing the patch. It appears that my logic of determining whether we are inside UPDATE/DELETE etc statement is not as full-proof as I thought. I will look further into it.

          As for the permission available through role rather than direct direct tests, I will attempt to add a standalong test fixture in RolesConferredPrivilegesTest.java The existing test fixtures are very sophisticated for what I need to test. If anyone has ideas on how I can use the existing test fixture in RolesConferredPrivilegesTest.java to add a test case like
          select t1.c1 from user1.t1, user1.t2
          Otherwise, I will just add a new test fixture to test above.

          Show
          Mamta A. Satoor added a comment - Rick, thanks for reviewing the patch. It appears that my logic of determining whether we are inside UPDATE/DELETE etc statement is not as full-proof as I thought. I will look further into it. As for the permission available through role rather than direct direct tests, I will attempt to add a standalong test fixture in RolesConferredPrivilegesTest.java The existing test fixtures are very sophisticated for what I need to test. If anyone has ideas on how I can use the existing test fixture in RolesConferredPrivilegesTest.java to add a test case like select t1.c1 from user1.t1, user1.t2 Otherwise, I will just add a new test fixture to test above.
          Hide
          Mamta A. Satoor added a comment -

          I have added another patch DERBY4191_miniumSelectPrivOnAllTables_diff_patch4.txt which is same as the previous one except that SubqueryNode during it's bind phase now requires minimum select privilege on all it's table. It fixes the test case you provided Rick. I have fired the derbyall and will run junit suite after that. In the mean time, I will work on adding a test case for this subquery scenario and will add test case for roles (as Rick pointed out in his last review).

          Show
          Mamta A. Satoor added a comment - I have added another patch DERBY4191_miniumSelectPrivOnAllTables_diff_patch4.txt which is same as the previous one except that SubqueryNode during it's bind phase now requires minimum select privilege on all it's table. It fixes the test case you provided Rick. I have fired the derbyall and will run junit suite after that. In the mean time, I will work on adding a test case for this subquery scenario and will add test case for roles (as Rick pointed out in his last review).
          Hide
          Mamta A. Satoor added a comment -

          While trying so more test cases, I found another test case for update that does not collect select privilege requirement.

          java -Dderby.database.sqlAuthorization=true -Dij.exceptionTrace=true org.apache.derby.tools.ij
          connect 'jdbc:derby:c:/dellater/db1;user=dbo;create=true' as dbo;
          create table t( a int, b int );
          grant update on t to public;
          connect 'jdbc:derby:c:/dellater/db1;user=user2' as user2;
          – with my last patch(DERBY4191_miniumSelectPrivOnAllTables_diff_patch4.txt), following now will give an error
          update dbo.t set a = ( select max(a) + 2 from dbo.t );
          --grant select privilege on dbo.t(a) to user2
          set connection dbo;
          grant select(a) on t to user2;
          set connection user2;
          – now the following will succeed
          update dbo.t set a = ( select max(a) + 2 from dbo.t );
          --BUT FOLLOWING SHOULD NOT SUCCEED because there is no select privilege on column b
          update dbo.t set a = ( select max(b) + 2 from dbo.t );

          So, it appears that we are not collecting individual select privilege for a subquery hidden inside update. I will look further into it. Wonder if there are other cases where we are missing on collecting the select privileges. I tried the test case about without my changes on a different trunk client(that client has some other changes but they are not related to privilege collection) and the buggy behavior can be seen there, too. I just wanted to be sure that my changes for this jira didn't cause any regression.

          Show
          Mamta A. Satoor added a comment - While trying so more test cases, I found another test case for update that does not collect select privilege requirement. java -Dderby.database.sqlAuthorization=true -Dij.exceptionTrace=true org.apache.derby.tools.ij connect 'jdbc:derby:c:/dellater/db1;user=dbo;create=true' as dbo; create table t( a int, b int ); grant update on t to public; connect 'jdbc:derby:c:/dellater/db1;user=user2' as user2; – with my last patch(DERBY4191_miniumSelectPrivOnAllTables_diff_patch4.txt), following now will give an error update dbo.t set a = ( select max(a) + 2 from dbo.t ); --grant select privilege on dbo.t(a) to user2 set connection dbo; grant select(a) on t to user2; set connection user2; – now the following will succeed update dbo.t set a = ( select max(a) + 2 from dbo.t ); --BUT FOLLOWING SHOULD NOT SUCCEED because there is no select privilege on column b update dbo.t set a = ( select max(b) + 2 from dbo.t ); So, it appears that we are not collecting individual select privilege for a subquery hidden inside update. I will look further into it. Wonder if there are other cases where we are missing on collecting the select privileges. I tried the test case about without my changes on a different trunk client(that client has some other changes but they are not related to privilege collection) and the buggy behavior can be seen there, too. I just wanted to be sure that my changes for this jira didn't cause any regression.
          Hide
          Mamta A. Satoor added a comment -

          I have another patch, DERBY4191_miniumSelectPrivOnAllTables_And_Subquery_diff_patch5.txt. The difference in this patch compared to earlier patches is it now collects the select privilege requirement for a subquery involved in a DML. eg of subquery are as follows
          update dbo.t set a = ( select max(a1) + 2 from dbo.t1 )
          update dbo.t set a = ( select max(b1) + 2 from dbo.t2 )
          For the queries above, we were not collecting any select privileges for the subquery. Instead we were requiring update privileges on columns inside the subquery. I have made changes in SubqueryNode to require the select privileges for the query it is working with. I have added tests for this subquery change in this patch.

          In addition to the above changes, I have added tests for testing privileges available through roles. These tests were missing from earlier patch for a query like
          select c1 from user1.t1, user1.t2

          Please review the patch and let me know of any issues you may see with it.

          Show
          Mamta A. Satoor added a comment - I have another patch, DERBY4191_miniumSelectPrivOnAllTables_And_Subquery_diff_patch5.txt. The difference in this patch compared to earlier patches is it now collects the select privilege requirement for a subquery involved in a DML. eg of subquery are as follows update dbo.t set a = ( select max(a1) + 2 from dbo.t1 ) update dbo.t set a = ( select max(b1) + 2 from dbo.t2 ) For the queries above, we were not collecting any select privileges for the subquery. Instead we were requiring update privileges on columns inside the subquery. I have made changes in SubqueryNode to require the select privileges for the query it is working with. I have added tests for this subquery change in this patch. In addition to the above changes, I have added tests for testing privileges available through roles. These tests were missing from earlier patch for a query like select c1 from user1.t1, user1.t2 Please review the patch and let me know of any issues you may see with it.
          Hide
          Mamta A. Satoor added a comment -

          BTW, I forgot to mention that derbyall ran fine with my patch and as for the junit tests, only saw the known failure in StressMultiTest which is DERBY-3916(which appears to be duplicate of DERBY-3757

          Show
          Mamta A. Satoor added a comment - BTW, I forgot to mention that derbyall ran fine with my patch and as for the junit tests, only saw the known failure in StressMultiTest which is DERBY-3916 (which appears to be duplicate of DERBY-3757
          Hide
          Rick Hillegas added a comment -

          Thanks for the new patch, Mamta. I am seeing some odd behavior around views and deletes. Here's a script which shows this odd behavior:

          connect 'jdbc:derby:memory:dummy;create=true;user=ruth;password=ruthpassword' as ruth_conn;

          create table t_ruth( a int, b int );
          create view v_ruth( c, d ) as select a, b from t_ruth;

          grant update on t_ruth to public;
          grant insert on t_ruth to public;
          grant delete on t_ruth to public;

          connect 'jdbc:derby:memory:dummy;user=alice;password=alicepassword' as alice_conn;

          – misleading error message on these queries
          – complains that User 'ALICE' does not have UPDATE permission on column 'C' of table 'RUTH'.'V_RUTH'.
          update ruth.t_ruth set a = ( select max(c) from ruth.v_ruth );
          update ruth.t_ruth set a = ( select count from ruth.v_ruth );
          update ruth.t_ruth set a = ( select 1 from ruth.v_ruth );

          – fails but should succeed
          – complains that User 'ALICE' does not have SELECT permission on table 'RUTH'.'T_RUTH'.
          delete from ruth.t_ruth;

          Show
          Rick Hillegas added a comment - Thanks for the new patch, Mamta. I am seeing some odd behavior around views and deletes. Here's a script which shows this odd behavior: connect 'jdbc:derby:memory:dummy;create=true;user=ruth;password=ruthpassword' as ruth_conn; create table t_ruth( a int, b int ); create view v_ruth( c, d ) as select a, b from t_ruth; grant update on t_ruth to public; grant insert on t_ruth to public; grant delete on t_ruth to public; connect 'jdbc:derby:memory:dummy;user=alice;password=alicepassword' as alice_conn; – misleading error message on these queries – complains that User 'ALICE' does not have UPDATE permission on column 'C' of table 'RUTH'.'V_RUTH'. update ruth.t_ruth set a = ( select max(c) from ruth.v_ruth ); update ruth.t_ruth set a = ( select count from ruth.v_ruth ); update ruth.t_ruth set a = ( select 1 from ruth.v_ruth ); – fails but should succeed – complains that User 'ALICE' does not have SELECT permission on table 'RUTH'.'T_RUTH'. delete from ruth.t_ruth;
          Hide
          Mamta A. Satoor added a comment -

          Attaching another patch, DERBY4191_miniumSelectPriv_CursorNode_And_Subquery_diff_patch6.txt. I have made couple changes in this patch compared to the previous Both the patches require that user had minimum select privileges on all the tables in the select list. But the earlier patch made that check in SelectNode whereas this patch makes that check in CursorNode. The reason for this is for a simple DMLlike following, delete from ruth.t_ruth, a SelectNode is generated. But that SelectNode is to generate the resultset needed for delete. From my research, I believe CursorNode is the correct node where the minimum select privilege requirement should go. I have added test cases mentioned by Rick for the earlier patch and those test cases along with all the existing tests run with no problem with this patch. Another change in this patch compared to earlier one is the select privilege requirement for subquery now happens around the entire bind time code in SubqueryNode rather than just aroiund resultSet.bindExpressions. Would appreciate if someone can review this patch for me to see if they see any problems with it.

          Show
          Mamta A. Satoor added a comment - Attaching another patch, DERBY4191_miniumSelectPriv_CursorNode_And_Subquery_diff_patch6.txt. I have made couple changes in this patch compared to the previous Both the patches require that user had minimum select privileges on all the tables in the select list. But the earlier patch made that check in SelectNode whereas this patch makes that check in CursorNode. The reason for this is for a simple DMLlike following, delete from ruth.t_ruth, a SelectNode is generated. But that SelectNode is to generate the resultset needed for delete. From my research, I believe CursorNode is the correct node where the minimum select privilege requirement should go. I have added test cases mentioned by Rick for the earlier patch and those test cases along with all the existing tests run with no problem with this patch. Another change in this patch compared to earlier one is the select privilege requirement for subquery now happens around the entire bind time code in SubqueryNode rather than just aroiund resultSet.bindExpressions. Would appreciate if someone can review this patch for me to see if they see any problems with it.
          Hide
          Rick Hillegas added a comment -

          Thanks for this new patch, Mamta. I have verified that the previously identified problem cases now behave properly. I have run out of problem queries to test against this patch. This looks like a very good improvement to me. Thanks.

          Show
          Rick Hillegas added a comment - Thanks for this new patch, Mamta. I have verified that the previously identified problem cases now behave properly. I have run out of problem queries to test against this patch. This looks like a very good improvement to me. Thanks.
          Hide
          Mamta A. Satoor added a comment -

          Thanks again for all your time, Rick. I have committed the patch(revision 898635) with following commit comments

          DERBY-4191

          Require minimum select privilege from the tables in the SELECT sql if no column is selected from the table by the user eg
          select count from root.t;
          select 1 from root.t;
          For the query above, Derby was letting the user execute the select even if the user had no select privilege available on root.t With this fix, Derby will check if there is atleast one column on which the user has select privilege available to it or if the user select privilege at the table level. If yes, only then the user will be able to select from another user's table.

          select myTable.a from myTable, admin.privateTable
          for the query above, since no column is selected specifically from admin.privateTable, Derby will now see if there is table level select privilege or atleast one column level select privilege available on admin.privatTable

          One other problem scenario was
          update ruth.t_ruth set a = ( select max(c) from ruth.v_ruth );
          For the query above, prior to fix for DERBY-4191, we were not looking for select privilege for the subquery. That has also been fixed with fix for DERBY-4191

          All the existing tests passed with no regression. Added few tests for the fixes involved in this jira.

          Show
          Mamta A. Satoor added a comment - Thanks again for all your time, Rick. I have committed the patch(revision 898635) with following commit comments DERBY-4191 Require minimum select privilege from the tables in the SELECT sql if no column is selected from the table by the user eg select count from root.t; select 1 from root.t; For the query above, Derby was letting the user execute the select even if the user had no select privilege available on root.t With this fix, Derby will check if there is atleast one column on which the user has select privilege available to it or if the user select privilege at the table level. If yes, only then the user will be able to select from another user's table. select myTable.a from myTable, admin.privateTable for the query above, since no column is selected specifically from admin.privateTable, Derby will now see if there is table level select privilege or atleast one column level select privilege available on admin.privatTable One other problem scenario was update ruth.t_ruth set a = ( select max(c) from ruth.v_ruth ); For the query above, prior to fix for DERBY-4191 , we were not looking for select privilege for the subquery. That has also been fixed with fix for DERBY-4191 All the existing tests passed with no regression. Added few tests for the fixes involved in this jira.
          Hide
          Dag H. Wanvik added a comment -

          Should this issue have a releaseNote (the change can break existing apps)?b

          Show
          Dag H. Wanvik added a comment - Should this issue have a releaseNote (the change can break existing apps)?b
          Hide
          Mamta A. Satoor added a comment -

          Dag, you are right about the release notes. I will work on creating one. I think there is a tool to generate one. I will look into it.

          Show
          Mamta A. Satoor added a comment - Dag, you are right about the release notes. I will work on creating one. I think there is a tool to generate one. I will look into it.
          Hide
          Mamta A. Satoor added a comment -

          Attaching release notes since this jira is going to change the Derby behavior by catching privilege violation which were incorrectly allowed earlier.

          Show
          Mamta A. Satoor added a comment - Attaching release notes since this jira is going to change the Derby behavior by catching privilege violation which were incorrectly allowed earlier.
          Hide
          Mamta A. Satoor added a comment -

          I am wondering if we should put anything in our docs about minimum select requirement when the query is not referencing any specific column from the tables in the FROM list. Already attached a release note for it.

          Show
          Mamta A. Satoor added a comment - I am wondering if we should put anything in our docs about minimum select requirement when the query is not referencing any specific column from the tables in the FROM list. Already attached a release note for it.
          Hide
          Dag H. Wanvik added a comment -

          +1 to a note in the docs about this requirement; it's not necessarily obvious..

          Show
          Dag H. Wanvik added a comment - +1 to a note in the docs about this requirement; it's not necessarily obvious..
          Hide
          Kim Haase added a comment -

          I can document this along with the changes to the SELECT statement topic that I am making for DERBY-4518, if that would be okay.

          Show
          Kim Haase added a comment - I can document this along with the changes to the SELECT statement topic that I am making for DERBY-4518 , if that would be okay.
          Hide
          Kim Haase added a comment -

          Since DERBY-4518 doesn't actually require any changes to the SELECT statement topic (I think), I've created a separate documentation issue for this (DERBY-4522).

          Show
          Kim Haase added a comment - Since DERBY-4518 doesn't actually require any changes to the SELECT statement topic (I think), I've created a separate documentation issue for this ( DERBY-4522 ).
          Hide
          Rick Hillegas added a comment -

          Hi Mamta,

          Can this issue be resolved now? Thanks.

          Show
          Rick Hillegas added a comment - Hi Mamta, Can this issue be resolved now? Thanks.
          Hide
          Mamta A. Satoor added a comment -

          Yes, it can be resolved. Thanks for pointing it out Rick. The changes at this point are only in 10.6 codeline.

          Show
          Mamta A. Satoor added a comment - Yes, it can be resolved. Thanks for pointing it out Rick. The changes at this point are only in 10.6 codeline.
          Hide
          Rick Hillegas added a comment -

          Attaching a new version of the release note. This version:

          1) Simplifies the summary so that the 10.6 release notes are more readable.

          2) Moves explanatory material out of html comments into the relevant release note subsections.

          Show
          Rick Hillegas added a comment - Attaching a new version of the release note. This version: 1) Simplifies the summary so that the 10.6 release notes are more readable. 2) Moves explanatory material out of html comments into the relevant release note subsections.
          Hide
          Lily Wei added a comment -

          Reopen to 10.5 back port

          Show
          Lily Wei added a comment - Reopen to 10.5 back port
          Hide
          Mike Matrigali added a comment -

          This issue has already been backported to 10.5, and should not have been reopened for the 10.5 backport effort.

          Show
          Mike Matrigali added a comment - This issue has already been backported to 10.5, and should not have been reopened for the 10.5 backport effort.

            People

            • Assignee:
              Mamta A. Satoor
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development