Hierarchical Visibility Strings

[Ed Kohlwey <ek...@gmail.com>]

It would be nice to support hierarchical visibility strings, so that an
application could use a URI to delegate control of a certain set of
visibilities to a particular organization that you'd like to have control
those visibilities. Ex: visibility://some.org/some-dept/visibility

You COULD use the existing characters to construct a hierarchical scheme,
but it would be more terse than a restricted URI and you'd have to get
pretty creative with your encoding.

It looks like you could add slash and period to the allowed characters
pretty easily by adding a new statement in Authorizations.class around line
62.

Any thoughts on pros/cons to doing so? Any interest in doing this in a 1.4
release?

Re: Hierarchical Visibility Strings

[David Medinets <da...@gmail.com>]

Does it make sense to have visibility syntax handlers within the
framework? For example, we could supporting label like "P1(....)" and
"P2(...)" if P1 and P2 are not recognized handlers then default to the
current syntax? I'm thinking that someone might want binary labels (to
improve speed?) in the future. Using a pluggable label handler would
allow future expansion.

Y'all have probably already discussed this kind of solution. And I'm
retreading old ground.

Re: Hierarchical Visibility Strings

[Ed Kohlwey <ek...@gmail.com>]

Adding quotes would be a little heavyweight for my purposes, but that
sounds like a good idea.

I don't think that letting in . and / characters would have a significant
negative effect on the grammar flexibility, especially since the resulting
expressiveness would be less than URI's, which have pretty reduced
expressivity themselves, but other people might have some use cases in mind
where this could be a problem.

On a separate but related note, the docs seem to say : isn't valid (see
http://accumulo.apache.org/1.4/apidocs/org/apache/accumulo/core/security/ColumnVisibility.html#ColumnVisibility(byte[]))
but the code does (see
https://github.com/apache/accumulo/blob/trunk/core/src/main/java/org/apache/accumulo/core/security/Authorizations.java)
on line 62

On Wed, Jul 11, 2012 at 4:56 PM, Keith Turner <ke...@deenlo.com> wrote:

> Ed,
>
> Seems like a good, standard way to avoid name collisions.   I do not
> think 1.4 is right place, 1.4.X release should mainly be bug fixes.
>
> At some point we had a detailed discussion about allowing more
> characters in the labels.  The con is that it takes away from future
> flexibility of the language.  I was advocating for supporting quoting
> and escaping labels instead taking away reserved chars.  So support
> expressions like  : 'vis://A/B' & 'vis://A/C'   where you can put any
> char between the quotes as long as quotes are properly escaped.
> There are a few standard escaping mechanisms we could choose from.
>
> Adding quoting should be done in a backwards compatible way.
>
> Keith
>
> On Wed, Jul 11, 2012 at 3:59 PM, Ed Kohlwey <ek...@gmail.com> wrote:
> > It would be nice to support hierarchical visibility strings, so that an
> > application could use a URI to delegate control of a certain set of
> > visibilities to a particular organization that you'd like to have control
> > those visibilities. Ex: visibility://some.org/some-dept/visibility
> >
> > You COULD use the existing characters to construct a hierarchical scheme,
> > but it would be more terse than a restricted URI and you'd have to get
> > pretty creative with your encoding.
> >
> > It looks like you could add slash and period to the allowed characters
> > pretty easily by adding a new statement in Authorizations.class around
> line
> > 62.
> >
> > Any thoughts on pros/cons to doing so? Any interest in doing this in a
> 1.4
> > release?
>

Re: Hierarchical Visibility Strings

[Keith Turner <ke...@deenlo.com>]

Ed,

Seems like a good, standard way to avoid name collisions.   I do not
think 1.4 is right place, 1.4.X release should mainly be bug fixes.

At some point we had a detailed discussion about allowing more
characters in the labels.  The con is that it takes away from future
flexibility of the language.  I was advocating for supporting quoting
and escaping labels instead taking away reserved chars.  So support
expressions like  : 'vis://A/B' & 'vis://A/C'   where you can put any
char between the quotes as long as quotes are properly escaped.
There are a few standard escaping mechanisms we could choose from.

Adding quoting should be done in a backwards compatible way.

Keith

On Wed, Jul 11, 2012 at 3:59 PM, Ed Kohlwey <ek...@gmail.com> wrote:
> It would be nice to support hierarchical visibility strings, so that an
> application could use a URI to delegate control of a certain set of
> visibilities to a particular organization that you'd like to have control
> those visibilities. Ex: visibility://some.org/some-dept/visibility
>
> You COULD use the existing characters to construct a hierarchical scheme,
> but it would be more terse than a restricted URI and you'd have to get
> pretty creative with your encoding.
>
> It looks like you could add slash and period to the allowed characters
> pretty easily by adding a new statement in Authorizations.class around line
> 62.
>
> Any thoughts on pros/cons to doing so? Any interest in doing this in a 1.4
> release?