Authorization failure when indexing document with new mappings to alias.

[jtibshirani]

Elasticsearch version (bin/elasticsearch --version): 6.2.4

Description of the problem including expected versus actual behavior:

If a user is allowed to write to an alias, but not its concrete index, then indexing a document with new mappings can produce the following authorization exception:

{
 "error" : {
   "root_cause" : [
     {
       "type" : "security_exception",
       "reason" : "action [indices:admin/mapping/put] is unauthorized for user [test_user]"
     }
   ],
   "type" : "security_exception",
   "reason" : "action [indices:admin/mapping/put] is unauthorized for user [test_user]"
 },
 "status" : 403
}

This behavior is confusing, because write permissions should allow for both indexing and updating mappings, and the user can successfully make a put mapping request directly.

Note that if the user is also given write privileges to the underlying index, then attempting to index the document succeeds. This fact suggests that the implicit mappings call during indexing is maybe being validated against the concrete index, instead of the alias.

Related to #29874.

Steps to reproduce:

Gist: https://gist.github.com/jtibshirani/ff8ebcd235dc8be36ecd84543b29525d

[elasticmachine]

Pinging @elastic/es-security

[jaymode]

This fact suggests that the implicit mappings call during indexing is maybe being validated against the concrete index, instead of the alias.

This is in fact the case and was an intentional change introduced in #17048. A couple of thoughts come to mind, we can add the original indices to the request or we can handle this case specifically within our authorization code. We currently already have a special case for this, so I am leaning towards expanding that with a fix.