Accumulo
  1. Accumulo
  2. ACCUMULO-739

Please add dot (.) as a valid character in column visibility tokens

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5.0
    • Component/s: client, master, rpc, test, tserver
    • Labels:
      None

      Description

      Please add dot (.) as a valid character in column visibility tokens. This would allow us to implement hierarchical access control mechanisms.

        Activity

        Hide
        Ivan Bella added a comment -

        Thank you Eric!

        Show
        Ivan Bella added a comment - Thank you Eric!
        Hide
        Eric Newton added a comment -

        ACCUMULO-241 already exists to beat the long-term issue of expanding label evaluation in the future. Patch applied, along with some trivial testing of the new characters in labels.

        Show
        Eric Newton added a comment - ACCUMULO-241 already exists to beat the long-term issue of expanding label evaluation in the future. Patch applied, along with some trivial testing of the new characters in labels.
        Hide
        Dave Marion added a comment -

        FYI, I didn't make the video (but I wish I did ).

        Show
        Dave Marion added a comment - FYI, I didn't make the video (but I wish I did ).
        Hide
        John Vines added a comment -

        Point made Dave (lol) and Ed.

        So can anyone here think of valid reasons for NOT allowing . and /?

        Show
        John Vines added a comment - Point made Dave (lol) and Ed. So can anyone here think of valid reasons for NOT allowing . and /?
        Hide
        Ed Kohlwey added a comment -

        Bringing this back around... There's a specific need on the part of a few users to add . and / in order to support hierarchical structure in labels. Can we settle on implementing this feature using the current whitelist approach and open a new ticket to discuss the long term strategy?

        Show
        Ed Kohlwey added a comment - Bringing this back around... There's a specific need on the part of a few users to add . and / in order to support hierarchical structure in labels. Can we settle on implementing this feature using the current whitelist approach and open a new ticket to discuss the long term strategy?
        Show
        Dave Marion added a comment - http://www.xtranormal.com/watch/13644605/accumulo-follies-volume-1
        Hide
        John Vines added a comment -

        Escaping will make parsing substantially more complicated, especially if you start going into nested quotations with some OTHER form of escaping. Perhaps an alternative for supporting a larger alphabet would be to adopt a custom encoding which ensures that no multi-byte characters consist of one of our reserved characters. This would allow us to continue to do speedy checks while still expanding the user base outside of English without concerns of encodings breaking their expressions.

        Show
        John Vines added a comment - Escaping will make parsing substantially more complicated, especially if you start going into nested quotations with some OTHER form of escaping. Perhaps an alternative for supporting a larger alphabet would be to adopt a custom encoding which ensures that no multi-byte characters consist of one of our reserved characters. This would allow us to continue to do speedy checks while still expanding the user base outside of English without concerns of encodings breaking their expressions.
        Hide
        Dave Marion added a comment -

        I didn't intend for my suggestion to mean the current set of reserved characters. I see no problem with defining a new set of reserved characters (current reserved + future).

        Show
        Dave Marion added a comment - I didn't intend for my suggestion to mean the current set of reserved characters. I see no problem with defining a new set of reserved characters (current reserved + future).
        Hide
        Ed Kohlwey added a comment -

        To follow up on that - I'll be deploying this patch on top of an Accumulo 1.4 instance in the next week or so unless another stable patch is submitted in the meantime. The proposed quote-based solution would break compatibility with that deployment, so in that case the introduction of the quote stuff will actually be a significant inconvenience.

        Show
        Ed Kohlwey added a comment - To follow up on that - I'll be deploying this patch on top of an Accumulo 1.4 instance in the next week or so unless another stable patch is submitted in the meantime. The proposed quote-based solution would break compatibility with that deployment, so in that case the introduction of the quote stuff will actually be a significant inconvenience.
        Hide
        Christopher Tubbs added a comment -

        Ed-

        I agree. I actually don't see a need to require quoting to use the dot character. I think it's reasonable to add it as a valid character in the labels, possibly along with spaces. My only point was to express disagreement with Dave's "allow all un-reserved characters", which could prevent any future enhancements.

        To Keith's idea, I think quoting could be nice in the future, though I agree that it might best be left to implement when that use case arrives. Also, it might be easier to avoid quoting entirely, and only provide escapes for reserved characters.

        Example: ((Sears|H\&M|Disney Store)&Store Manager)
        vs.: ((Sears|"H&M"|"Disney Store")&"Store Manager")

        Show
        Christopher Tubbs added a comment - Ed- I agree. I actually don't see a need to require quoting to use the dot character. I think it's reasonable to add it as a valid character in the labels, possibly along with spaces. My only point was to express disagreement with Dave's "allow all un-reserved characters", which could prevent any future enhancements. To Keith's idea, I think quoting could be nice in the future, though I agree that it might best be left to implement when that use case arrives. Also, it might be easier to avoid quoting entirely, and only provide escapes for reserved characters. Example: ((Sears|H\&M|Disney Store)&Store Manager) vs.: ((Sears|"H&M"|"Disney Store")&"Store Manager")
        Hide
        Ed Kohlwey added a comment -

        Keith, that would be fantastic.

        I still want to pose the question: what future use cases are the characters being reserved against? We're proposing what is arguably the smallest meaningful subset of URI's, which is already a highly restricted (although widely accepted) grammar for hierarchical resource identification. To Chris's point, this is not utilizing characters that are commonly used for other purposes, or even characters that are part of the URI syntax but less commonly used. This is a bare minimum for hierarchical expressivity.

        Accumulo has been through quite a few major revisions and (as far as I know) the only changes to this component that have ever been implemented involve adding characters to the grammar to make label structure more expressive.

        I just want to suggest that its better to focus on problems that people have today rather than ones people might have tomorrow.

        Show
        Ed Kohlwey added a comment - Keith, that would be fantastic. I still want to pose the question: what future use cases are the characters being reserved against? We're proposing what is arguably the smallest meaningful subset of URI's, which is already a highly restricted (although widely accepted) grammar for hierarchical resource identification. To Chris's point, this is not utilizing characters that are commonly used for other purposes, or even characters that are part of the URI syntax but less commonly used. This is a bare minimum for hierarchical expressivity. Accumulo has been through quite a few major revisions and (as far as I know) the only changes to this component that have ever been implemented involve adding characters to the grammar to make label structure more expressive. I just want to suggest that its better to focus on problems that people have today rather than ones people might have tomorrow.
        Hide
        Keith Turner added a comment -

        I think we should support quoting and escaping of quotes. We should continue to support unquoted literals as long as they conform to current rules. Then users can use whatever characters they like and characters like . are reserved for future use. If we allow dot and slash now, they will be lost for future use.

         A & ('B.C' | 'B.D')
        

        I will create a patch supporting quoting for consideration later this week.

        Show
        Keith Turner added a comment - I think we should support quoting and escaping of quotes. We should continue to support unquoted literals as long as they conform to current rules. Then users can use whatever characters they like and characters like . are reserved for future use. If we allow dot and slash now, they will be lost for future use. A & ('B.C' | 'B.D') I will create a patch supporting quoting for consideration later this week.
        Hide
        John Vines added a comment -

        technically, yes. but I'm going to say no to that idea. This is one of our unique features and making it pluggable can lead to confusion to users as well as support hell for us.

        Show
        John Vines added a comment - technically, yes. but I'm going to say no to that idea. This is one of our unique features and making it pluggable can lead to confusion to users as well as support hell for us.
        Hide
        David Medinets added a comment -

        Since there seems to be a difference of opinion, can the visibility label syntax be pluggable?

        Show
        David Medinets added a comment - Since there seems to be a difference of opinion, can the visibility label syntax be pluggable?
        Hide
        Christopher Tubbs added a comment -

        Allowing all un-reserved characters has the unfortunate side-effect of making any future enhancements to the visibility grammar impossible to retain backwards-compatibility.

        I'm in favor of expanding the allowed character set to include characters typically allowed in identifiers in other languages, including dots.

        I think parenthetical punctuation of all types, as well as question marks, quotations, exclamation points, and and other characters typically used as operators or delimiters in many languages, as reserved for future enhancements, if necessary.

        Show
        Christopher Tubbs added a comment - Allowing all un-reserved characters has the unfortunate side-effect of making any future enhancements to the visibility grammar impossible to retain backwards-compatibility. I'm in favor of expanding the allowed character set to include characters typically allowed in identifiers in other languages, including dots. I think parenthetical punctuation of all types, as well as question marks, quotations, exclamation points, and and other characters typically used as operators or delimiters in many languages, as reserved for future enhancements, if necessary.
        Hide
        Dave Marion added a comment -

        I think that we should allow all un-reserved characters instead of allowing specific characters.

        Show
        Dave Marion added a comment - I think that we should allow all un-reserved characters instead of allowing specific characters.
        Hide
        Ed Kohlwey added a comment -

        Here's a patch implementing both . and /

        Show
        Ed Kohlwey added a comment - Here's a patch implementing both . and /
        Hide
        Ed Kohlwey added a comment -

        I would also like to ask for / to be added. The fix for this is very simple - just add two lines to Authorizations.

        There was some discussion on the mailing list with Keith suggesting that the implementor of this feature also implement it such that it would work only within single quotes, so that more characters could be reserved for the grammar in the future.

        My investigation showed that this would be quite a bit of work, and I'm not sure its worth it. The only other character that I think you might want to add would be a not - and we still have ! and ^ to fall back on for this.

        I'd like to ask that this be submitted for 1.5 unless someone else is willing to implement the alternate, single quote solution.

        Show
        Ed Kohlwey added a comment - I would also like to ask for / to be added. The fix for this is very simple - just add two lines to Authorizations. There was some discussion on the mailing list with Keith suggesting that the implementor of this feature also implement it such that it would work only within single quotes, so that more characters could be reserved for the grammar in the future. My investigation showed that this would be quite a bit of work, and I'm not sure its worth it. The only other character that I think you might want to add would be a not - and we still have ! and ^ to fall back on for this. I'd like to ask that this be submitted for 1.5 unless someone else is willing to implement the alternate, single quote solution.

          People

          • Assignee:
            Billie Rinaldi
            Reporter:
            Ivan Bella
          • Votes:
            1 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development