Redundant check in java.security.BasicPermission.implies()

[Alex Yursha]

The javadocs for the class java.security.BasicPermission says, that the
naming convention for BasicPermission names follows the hierarchical
property naming convention with possible wildcards. AFAIU, *hierarchical
property naming convention* assumes that you specify either a simple
identifier like *user*, or a sequence of dot-separated identifiers
like *user.group.id
<http://user.group.id> - *so what is the purpose for names like *user. *with
a dot at the end? It seems like it contradicts the documentation and has no
purpose.


On Fri, Nov 29, 2013 at 8:16 PM, Tom Hawtin <tom.hawtin at oracle.com> wrote:

> On 29/11/2013 15:46, Alex Yursha wrote:
>
>  // make sure ap.path is longer so a.b.* doesn't imply a.b
>>
>                                                            ^.
> Somebody has removed the full stop from the sentence fragment. I'll give
> you that this class API docs should be better.
>
>
>                  return (that.path.length() > this.path.length()) &&
>>                     that.path.startsWith(this.path);
>>
>
>  As the highlighted comment states, the length comparison check is
>> performed in order to prevent such cases where "a.b.*" would imply
>> "a.b". But the contract for java.lang.String.startsWith() is such that
>> if the prefix length is greater than the string length than that test
>> will fail. So it seems like java.security.BasicPermission.implies()
>> tries to duplicate the check that is performed by
>> java.lang.String.startswith() out of the box.
>>
>
> So, suppose we had permissions with names "a.b.*" and "a.b.". These have
> paths "a.b." and "a.b." (respectively, or not). startsWith will return
> true, but the length comparison false.
>
> So
>
>  - the check is not redundant
>  - a.b. is not implied by a.b.*
>  - BasicPermission does not correctly specify behaviour of wildcards
>      (should probably have a CR)
>
> Tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20131129/c144c89f/attachment.htm>