Elasticsearch: NPE in _analyze api in 6.5.4 with security

[markharwood]

A user has reported that this causes a NullPointerException

POST _analyze?error_trace=true
{
  "tokenizer": "standard",
  "text": "The foo_bar_size's is 5."
}

@eedugon has reproduced but it would not reproduce for me on 6.5.4 without security.
The reported stack trace starts with security performing a filter for index names

java.lang.NullPointerException: null
        at org.apache.lucene.util.automaton.CharacterRunAutomaton.run(CharacterRunAutomaton.java:47) ~[lucene-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - jimczi - 2018-09-18 13:01:13]
        at org.elasticsearch.xpack.core.security.support.Automatons$1.test(Automatons.java:213) ~[?:?]
        at org.elasticsearch.xpack.core.security.support.Automatons$1.test(Automatons.java:210) ~[?:?]
        at java.util.stream.MatchOps$1MatchSink.accept(MatchOps.java:90) ~[?:1.8.0_161]
        at java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958) ~[?:1.8.0_161]
        at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126) ~[?:1.8.0_161]
        at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498) ~[?:1.8.0_161]
        at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485) ~[?:1.8.0_161]
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_161]
        at java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:230) ~[?:1.8.0_161]
        at java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:196) ~[?:1.8.0_161]
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_161]
        at java.util.stream.ReferencePipeline.allMatch(ReferencePipeline.java:454) ~[?:1.8.0_161]
        at org.elasticsearch.xpack.security.audit.logfile.LoggingAuditTrail$EventFilterPolicy.lambda$ignorePredicate$1(LoggingAuditTrail.java:860) ~[?:?]
...

..note however that this REST call does not target an index which is likely the source of the problem.

[elasticmachine]

Pinging @elastic/es-security

[elasticmachine]

Pinging @elastic/es-search

[markharwood]

@albertzaharovits apparently @eedugon has _not_ reproduced. My bad.
The issue seems like there may be something environmental to it. User has 2 self hosted systems with same setup but one started exhibiting this problem where previously it worked OK.

[albertzaharovits]

@markharwood I have reproduced it. You are right with your assumption about the indices request with a null index ;) I will have a fix soon.

[markharwood]

@albertzaharovits
Great, thanks! I presume adding _any_ accessible index name into the URL would be a temporary workaround? (Bearing in mind they're testing with core's standard tokenizer)

[albertzaharovits]

@markharwood

I presume adding any accessible index name into the URL would be a temporary workaround? (Bearing in mind they're testing with core's standard tokenizer)

Yes, that is correct!