Derby
  1. Derby
  2. DERBY-4161

SQL Roles - Clarify documentation regarding the SET ROLE

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.5.1.1
    • Fix Version/s: 10.5.2.0, 10.6.1.0
    • Component/s: Documentation
    • Labels:
      None

      Description

      After discussing this issue on the mailing list, it has been agreed that the documentation regarding the usage of SQL roles needs to be clarified.

      Namely, it should be clearer that a session does not have a role set by default and that as such, a SET ROLE must be issued to enable a specific role.

      Further along the path, we may want to have the ability of setting a default role but for now and for the release of 10.5 this is the shortest and best course to follow.

      Kim had already suggested an addition to the documentation on the list; maybe she'd like to take on this issue?

      1. cdevcsecureroles.html
        13 kB
        Kim Haase
      2. cdevcsecureroles.html
        13 kB
        Kim Haase
      3. DERBY-4161.diff
        5 kB
        Kim Haase
      4. DERBY-4161-2.diff
        5 kB
        Kim Haase

        Issue Links

          Activity

          Hide
          Kim Haase added a comment -

          Fix has appeared in latest alpha manuals, so closing issue.

          Show
          Kim Haase added a comment - Fix has appeared in latest alpha manuals, so closing issue.
          Hide
          Kim Haase added a comment - - edited

          I haven't heard that further corrections are needed, so I gather the latest patch is okay.

          Committed patch DERBY-4161-2.diff to documentation trunk at revision 772996.
          Merged to 10.5 branch at revision 772999.

          Show
          Kim Haase added a comment - - edited I haven't heard that further corrections are needed, so I gather the latest patch is okay. Committed patch DERBY-4161 -2.diff to documentation trunk at revision 772996. Merged to 10.5 branch at revision 772999.
          Hide
          Kim Haase added a comment -

          Thanks for those suggestions, Dag. I'm attaching DERBY-4161-2.diff (and cdevcsecureroles.html), which makes the changes you suggest and also changes some of the preceding text to the third person so there is no longer an abrupt shift between second and third person ("you" vs. "the user"). That had been bothering me.

          Please let me know if further corrections are needed. Thanks!

          Show
          Kim Haase added a comment - Thanks for those suggestions, Dag. I'm attaching DERBY-4161 -2.diff (and cdevcsecureroles.html), which makes the changes you suggest and also changes some of the preceding text to the third person so there is no longer an abrupt shift between second and third person ("you" vs. "the user"). That had been bothering me. Please let me know if further corrections are needed. Thanks!
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Kim! Sorry for the late comment on this issue.
          Looks good, just one clarification:

          > SET ROLE taskLeaderA;

          > If the database owner granted the taskLeaderA role to a user, that user would have all the privileges associated with the > taskLeaderA, updater, and reader roles.

          The first part of the above statement is a bit misleading, in that if the role has not been granted to the user,
          the SET ROLE statement would fail. Perhaps say,

          Presuming the database owner granted the taskLeaderA role to a user, that user be allowed to set the role as shown and would have all the privileges granted to the taskLeaderA, updater, and reader roles.

          Show
          Dag H. Wanvik added a comment - Thanks, Kim! Sorry for the late comment on this issue. Looks good, just one clarification: > SET ROLE taskLeaderA; > If the database owner granted the taskLeaderA role to a user, that user would have all the privileges associated with the > taskLeaderA, updater, and reader roles. The first part of the above statement is a bit misleading, in that if the role has not been granted to the user, the SET ROLE statement would fail. Perhaps say, Presuming the database owner granted the taskLeaderA role to a user, that user be allowed to set the role as shown and would have all the privileges granted to the taskLeaderA, updater, and reader roles.
          Hide
          Kim Haase added a comment -

          Attaching DERBY-4161.diff and cdevcsecureroles.html, containing edits to to the Using SQL Roles topic.

          M src/devguide/cdevcsecureroles.dita

          I changed two misleading role names in addition to modifying the section on setting roles. Thanks for any feedback.

          Show
          Kim Haase added a comment - Attaching DERBY-4161 .diff and cdevcsecureroles.html, containing edits to to the Using SQL Roles topic. M src/devguide/cdevcsecureroles.dita I changed two misleading role names in addition to modifying the section on setting roles. Thanks for any feedback.
          Hide
          Kim Haase added a comment -

          We won't be sure of the fix version until we make the fix, but we do know what version is affected.

          Show
          Kim Haase added a comment - We won't be sure of the fix version until we make the fix, but we do know what version is affected.
          Hide
          Kim Haase added a comment -

          What I suggested was that in the topic http://db.apache.org/derby/docs/dev/devguide/cdevcsecureroles.html some text along these lines should be added:

          For example, if you created and granted the roles shown in the previous session, you would have to issue a SET ROLE statement to have them take effect. For example, suppose you used the following statement;

          SET ROLE taskLeaderA;

          If the database owner granted the taskLeaderA role to a user, that user would have all the privileges associated with the taskLeaderA, updateUser and readUser roles.

          Also Tiago pointed out that it's confusing to have role names that end with "User" – readers might confuse them with user names. I'll make that change too unless I hear otherwise.

          Show
          Kim Haase added a comment - What I suggested was that in the topic http://db.apache.org/derby/docs/dev/devguide/cdevcsecureroles.html some text along these lines should be added: For example, if you created and granted the roles shown in the previous session, you would have to issue a SET ROLE statement to have them take effect. For example, suppose you used the following statement; SET ROLE taskLeaderA; If the database owner granted the taskLeaderA role to a user, that user would have all the privileges associated with the taskLeaderA, updateUser and readUser roles. Also Tiago pointed out that it's confusing to have role names that end with "User" – readers might confuse them with user names. I'll make that change too unless I hear otherwise.

            People

            • Assignee:
              Kim Haase
              Reporter:
              Tiago R. Espinha
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development