Derby
  1. Derby
  2. DERBY-4505

Document that views, triggers, and constraints run with definer's rights rather than invoker's rights

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.2.2.1, 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.1.0
    • Fix Version/s: 10.6.1.0
    • Component/s: Documentation
    • Labels:
      None

      Description

      Comments like the following can be found in the code, including this particular example from DDLConstantAction.storeConstraintDependenciesOnPrivileges():

      • Views and triggers and constraints run with definer's privileges.

      This is an important behavior of Derby privileges which deserves to be documented. I can find only one glancing reference to this behavior, viz., in the Reference Guide section on the REVOKE command. There we learn that:

      "You must use the RESTRICT clause on REVOKE statements for routines. The RESTRICT clause specifies that the EXECUTE privilege cannot be revoked if the specified routine is used in a view, trigger, or constraint, and the privilege is being revoked from the owner of the view, trigger, or constraint."

      From that lone statement, a clever reader might deduce that Derby views, triggers, and constraints run with definer rather than invoker rights. But that is not the clear meaning of that statement in the Reference Guide. To draw the necessary conclusion from that statement the reader would have to be clever enough to understand the SQL Standard's tricky language around definer and invoker rights--and that would be a very clever reader indeed.

      In short, we need to document this behavior explicitly. I consider this hole in our documentation to be a serious enough defect that I am marking this issue as a Bug.

      1. DERBY-4505-2.zip
        29 kB
        Kim Haase
      2. DERBY-4505-2.diff
        23 kB
        Kim Haase
      3. DERBY-4505.zip
        29 kB
        Kim Haase
      4. DERBY-4505.stat
        0.3 kB
        Kim Haase
      5. DERBY-4505.diff
        16 kB
        Kim Haase

        Activity

        Hide
        Kim Haase added a comment -

        Thanks very much, Rick.

        Committed patch DERBY-4505-2.diff to documentation trunk at revisions 898089 and 898091.

        Show
        Kim Haase added a comment - Thanks very much, Rick. Committed patch DERBY-4505 -2.diff to documentation trunk at revisions 898089 and 898091.
        Hide
        Rick Hillegas added a comment -

        Hi Kim. These modifications look good to me. Thanks.

        Show
        Rick Hillegas added a comment - Hi Kim. These modifications look good to me. Thanks.
        Hide
        Kim Haase added a comment -

        Attaching DERBY-4505-2.diff and DERBY-4505-2.zip with some more changes to reflect the comments made so far. Please let me know if more are needed. Thanks!

        Show
        Kim Haase added a comment - Attaching DERBY-4505 -2.diff and DERBY-4505 -2.zip with some more changes to reflect the comments made so far. Please let me know if more are needed. Thanks!
        Hide
        Kim Haase added a comment -

        I'll try to fix these topics to use the term privilege instead of permission, Dag – changes may be required in other topics too, but that should probably be done with a separate issue.

        I'll fix the grammar error and organization too.

        Show
        Kim Haase added a comment - I'll try to fix these topics to use the term privilege instead of permission, Dag – changes may be required in other topics too, but that should probably be done with a separate issue. I'll fix the grammar error and organization too.
        Hide
        Kim Haase added a comment -

        Thanks to you both for commenting even though I forgot to mark the issue Patch Available.

        Show
        Kim Haase added a comment - Thanks to you both for commenting even though I forgot to mark the issue Patch Available.
        Hide
        Rick Hillegas added a comment -

        Thanks, Kim. These modifications look like an improvement to me. In reviewing these changes, I tripped across a pre-existing grammar error on one of the pages. It would be good to fix that while you're in there. The page is cdevsecuregrantrevoke. I believe that we should remove the second "on" from the clause "on which the object depends on".

        I agree with your recommendation that we should raise the visibility of the new topic by making it parallel to "Using SQL standard authorization". Thanks.

        Show
        Rick Hillegas added a comment - Thanks, Kim. These modifications look like an improvement to me. In reviewing these changes, I tripped across a pre-existing grammar error on one of the pages. It would be good to fix that while you're in there. The page is cdevsecuregrantrevoke. I believe that we should remove the second "on" from the clause "on which the object depends on". I agree with your recommendation that we should raise the visibility of the new topic by making it parallel to "Using SQL standard authorization". Thanks.
        Hide
        Dag H. Wanvik added a comment -

        I think "privilege" is the right word to use; this is what the SQL standard uses.

        Show
        Dag H. Wanvik added a comment - I think "privilege" is the right word to use; this is what the SQL standard uses.
        Hide
        Kim Haase added a comment -

        Thanks for all your help, Rick.

        Attaching DERBY-4505.diff, DERBY-4505.stat, and DERBY-4505.zip, containing modifications to topics in the Developer's Guide and Reference Manual (including one new topic).

        Please let me know what further changes would be helpful. I did a few tweaks to clarify that permissions and privileges are the same thing but didn't try any wholesale changes.

        I'm thinking that the new topic might as well be on the same level as "Using SQL standard authorization" rather than a subtopic of it – would that make sense?

        Show
        Kim Haase added a comment - Thanks for all your help, Rick. Attaching DERBY-4505 .diff, DERBY-4505 .stat, and DERBY-4505 .zip, containing modifications to topics in the Developer's Guide and Reference Manual (including one new topic). Please let me know what further changes would be helpful. I did a few tweaks to clarify that permissions and privileges are the same thing but didn't try any wholesale changes. I'm thinking that the new topic might as well be on the same level as "Using SQL standard authorization" rather than a subtopic of it – would that make sense?
        Hide
        Rick Hillegas added a comment -

        Hi Kim. Here's what I think:

        >The topic on the REVOKE statement says,
        >
        >"You can revoke privileges for an object if you are the owner of the object or the database owner."
        >
        >Would the statement that "Views, triggers, and constraints operate with the permissions of the owner of the view, trigger, or constraint" add anything to this statement, or would it be redundant? Perhaps these things are not actually objects?

        I don't think that the additional sentence would add information. The existing sentence seems accurate and concise to me.

        >I'm also wondering if there is a difference between "privileges" and "permissions". Currently, the topic "Using SQL standard authorization" talks about privileges in its first sections but then switches to the term "permissions" for the subsection on views, triggers, and constraints. Is there a real distinction here or should we say "privileges" throughout? Or does "privileges" apply to objects and "permissions" to these other things?

        The terms "privileges" and "permissions" are synonyms. I can see that switching back and forth between the two terms confuses readers.

        >The GRANT statement topic currently says, "You can grant privileges to database objects that you are authorized to grant." This seems a bit circular (as well as ungrammatical). Would it make sense to use the same language as for REVOKE, that is, "You can grant privileges on an object if you are the owner of the object or the database owner"?

        I agree that the current statement sounds pretty goofy. I think that your proposed re-wording is clear, accurate, and better. We may need to revisit this topic if we ever implement the 'WITH GRANT OPTION" clause, but I wouldn't worry about that possibility right now. Thanks.

        Show
        Rick Hillegas added a comment - Hi Kim. Here's what I think: >The topic on the REVOKE statement says, > >"You can revoke privileges for an object if you are the owner of the object or the database owner." > >Would the statement that "Views, triggers, and constraints operate with the permissions of the owner of the view, trigger, or constraint" add anything to this statement, or would it be redundant? Perhaps these things are not actually objects? I don't think that the additional sentence would add information. The existing sentence seems accurate and concise to me. >I'm also wondering if there is a difference between "privileges" and "permissions". Currently, the topic "Using SQL standard authorization" talks about privileges in its first sections but then switches to the term "permissions" for the subsection on views, triggers, and constraints. Is there a real distinction here or should we say "privileges" throughout? Or does "privileges" apply to objects and "permissions" to these other things? The terms "privileges" and "permissions" are synonyms. I can see that switching back and forth between the two terms confuses readers. >The GRANT statement topic currently says, "You can grant privileges to database objects that you are authorized to grant." This seems a bit circular (as well as ungrammatical). Would it make sense to use the same language as for REVOKE, that is, "You can grant privileges on an object if you are the owner of the object or the database owner"? I agree that the current statement sounds pretty goofy. I think that your proposed re-wording is clear, accurate, and better. We may need to revisit this topic if we ever implement the 'WITH GRANT OPTION" clause, but I wouldn't worry about that possibility right now. Thanks.
        Hide
        Kim Haase added a comment -

        The topic won't be hard to find as long as we provide its title so people can search for it. There are a lot of buried topics that don't make the TOC, I think.

        I have some more questions –

        The topic on the REVOKE statement says,

        "You can revoke privileges for an object if you are the owner of the object or the database owner."

        Would the statement that "Views, triggers, and constraints operate with the permissions of the owner of the view, trigger, or constraint" add anything to this statement, or would it be redundant? Perhaps these things are not actually objects?

        I'm also wondering if there is a difference between "privileges" and "permissions". Currently, the topic "Using SQL standard authorization" talks about privileges in its first sections but then switches to the term "permissions" for the subsection on views, triggers, and constraints. Is there a real distinction here or should we say "privileges" throughout? Or does "privileges" apply to objects and "permissions" to these other things?

        The GRANT statement topic currently says, "You can grant privileges to database objects that you are authorized to grant." This seems a bit circular (as well as ungrammatical). Would it make sense to use the same language as for REVOKE, that is, "You can grant privileges on an object if you are the owner of the object or the database owner"?

        Show
        Kim Haase added a comment - The topic won't be hard to find as long as we provide its title so people can search for it. There are a lot of buried topics that don't make the TOC, I think. I have some more questions – The topic on the REVOKE statement says, "You can revoke privileges for an object if you are the owner of the object or the database owner." Would the statement that "Views, triggers, and constraints operate with the permissions of the owner of the view, trigger, or constraint" add anything to this statement, or would it be redundant? Perhaps these things are not actually objects? I'm also wondering if there is a difference between "privileges" and "permissions". Currently, the topic "Using SQL standard authorization" talks about privileges in its first sections but then switches to the term "permissions" for the subsection on views, triggers, and constraints. Is there a real distinction here or should we say "privileges" throughout? Or does "privileges" apply to objects and "permissions" to these other things? The GRANT statement topic currently says, "You can grant privileges to database objects that you are authorized to grant." This seems a bit circular (as well as ungrammatical). Would it make sense to use the same language as for REVOKE, that is, "You can grant privileges on an object if you are the owner of the object or the database owner"?
        Hide
        Rick Hillegas added a comment -

        Hi Kim,

        Thanks for picking up this issue. It's too bad that the topics won't show up in the pdf and single html versions. I don't know if the pdf version is widely used. However, I have noticed that conversations on the user list frequently refer to links into the single html versions.

        Show
        Rick Hillegas added a comment - Hi Kim, Thanks for picking up this issue. It's too bad that the topics won't show up in the pdf and single html versions. I don't know if the pdf version is widely used. However, I have noticed that conversations on the user list frequently refer to links into the single html versions.
        Hide
        Kim Haase added a comment -

        About the TOC issue – the new topic (and its parent, "Using SQL standard authorization") show up in the HTML pages TOC and in the left-side bookmarks for the PDF, but they are both nested too deeply to show up in the regular TOC in the PDF and HTML single versions, which only go down 3 levels. Hope this isn't a major concern.

        Rewriting the security documentation might change this, and there might be a way to change the TOC nesting level generally (though it appears to be buried deep in the DITA toolkit).

        Show
        Kim Haase added a comment - About the TOC issue – the new topic (and its parent, "Using SQL standard authorization") show up in the HTML pages TOC and in the left-side bookmarks for the PDF, but they are both nested too deeply to show up in the regular TOC in the PDF and HTML single versions, which only go down 3 levels. Hope this isn't a major concern. Rewriting the security documentation might change this, and there might be a way to change the TOC nesting level generally (though it appears to be buried deep in the DITA toolkit).
        Hide
        Kim Haase added a comment -

        Thanks, Rick.

        To get that section into the TOC, I'll have to make it into a separate topic – seems very worthwhile, so then we can reference it directly (though not, sadly, link to it from other books).

        I may need some help with the language on invoker/definer rights, but you can do that when you review the draft changes.

        Show
        Kim Haase added a comment - Thanks, Rick. To get that section into the TOC, I'll have to make it into a separate topic – seems very worthwhile, so then we can reference it directly (though not, sadly, link to it from other books). I may need some help with the language on invoker/definer rights, but you can do that when you review the draft changes.
        Hide
        Rick Hillegas added a comment -

        Thanks for finding this documentation, Kim. In addition to adding the pointers you mention, I think that the following changes would help people find this material:

        o Add a pointer in the Reference Guide section for the GRANT statement

        o Add the "Permissions on views, triggers, and constraints" subsection to the table of contents in the Developer Guide. This is probably the change which will be most useful to people looking for this material.

        o Add a little language to the subsection explaining that we are talking about what the SQL Standard calls "invoker" vs "definer" rights. Those keywords should be flagged for inclusion in an index, in case we ever get around to re-enabling the index. This change will help people search the documentation for these concepts, using their standard names.

        Thanks,
        -Rick

        Show
        Rick Hillegas added a comment - Thanks for finding this documentation, Kim. In addition to adding the pointers you mention, I think that the following changes would help people find this material: o Add a pointer in the Reference Guide section for the GRANT statement o Add the "Permissions on views, triggers, and constraints" subsection to the table of contents in the Developer Guide. This is probably the change which will be most useful to people looking for this material. o Add a little language to the subsection explaining that we are talking about what the SQL Standard calls "invoker" vs "definer" rights. Those keywords should be flagged for inclusion in an index, in case we ever get around to re-enabling the index. This change will help people search the documentation for these concepts, using their standard names. Thanks, -Rick
        Hide
        Kim Haase added a comment -

        There's a section in the "Using SQL standard authorization" topic of the Developer's Guide that I think may cover this. See http://db.apache.org/derby/docs/dev/devguide/cdevcsecuregrantrevokeaccess.html – the subsection "Permissions on views, triggers, and constraints".

        Is this the required information? If so, we need to provide a pointer to it, probably in the reference topics on CREATE TRIGGER and CREATE VIEW and the CONSTRAINT clause – anywhere else? The topic on the REVOKE statement already points to the "Using SQL standard authorization" topic.

        Show
        Kim Haase added a comment - There's a section in the "Using SQL standard authorization" topic of the Developer's Guide that I think may cover this. See http://db.apache.org/derby/docs/dev/devguide/cdevcsecuregrantrevokeaccess.html – the subsection "Permissions on views, triggers, and constraints". Is this the required information? If so, we need to provide a pointer to it, probably in the reference topics on CREATE TRIGGER and CREATE VIEW and the CONSTRAINT clause – anywhere else? The topic on the REVOKE statement already points to the "Using SQL standard authorization" topic.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development