Fix Has Privilege API check on restricted indices

[albertzaharovits]

The Has Privileges API allows to tap into the authorization process, to validate privileges without actually running the operations to be authorized. This fixes a bug, uncovered by Tim, in which the Has Privilege API returned spurious results when checking for index privileges over restricted indices (currently .security, .security-6, .security-7). The actual authorization process is not affected by the bug.

Wildcards of index names in the Has Privileges's request do not implicitly cover restricted indices. Concretely, calling:

GET /_security/user/_has_privileges
{
  "index" : [
    {
      "names": [ ".sec*", ".security*" ],
      "privileges": [ "read" ]
    }
  ]
}

and getting back a response such as:

{
  "has_all_requested" : false,
  "index" : {
    ".sec*" : {
      "read" : false
    },
    ".security*" : {
      "read" : true
    }
  }

Does not mean the user is authorized to read the indices .security, .security-6, .security-7 , even though the output says .security*: { "read": true } (and these indices match the wildcard). They might, or they might not, depending on the permissions definition. Implicitly, the API assumes the caller is not interested on privileges over these indices so the wildcard is not considering them.
If the caller is interested in privileges over these restricted indices, it should change the request as such:

GET /_security/user/_has_privileges
{
  "index" : [
    {
      "names": [ ".sec*", ".security*" ],
      "privileges": [ "read" ]
    }
  ],
  "allow_restricted_indieces": true
}

And now the wildcards expand to include the special indices. If the response is true (the same response as above), the the read operation is indeed authorized on .security, .security-6, .security-7 .

Passing the allow_restricted_indices is required even when checking privileges using explicit index names (no wildcards). And this is where the bug manifested: basically the result was bogus when explicitly checking privileges over restricted indices explicitly mentioned, but without setting the allow_restricted_indices flag.

The fix treats explicit restricted indices, without the allow_restricted_indices: true flag, in the request, as an IllegalArgumentException (400 error). If the flag is specified, the API correctly validates the privilege.

[elasticmachine]

Pinging @elastic/es-security

[albertzaharovits]

@tvernum you are right that the 400 error is not suitable for a fix in a patch version.

I and @jkakavas gathered and decided it's better to do the proper check on the restricted indices (.security, .security-6 and .security-7) when they are mentioned explicitly, even if the allow_restricted_indices parameter is not explicitly set to true.
The original intention of the allow_restricted_indices parameter was as an escape hatch for wildcard expansions that do not implicitly cover restricted indices, for the cases that the wildcard should do that (very rarely, and not a use case we recommend). It was extended to explicit restricted indices, without thinking it through, on consistency basis.

[albertzaharovits]

@jkakavas this is ready for review.

[jkakavas]

LGTM

[jkakavas]

Is it worth adding one sentence in the end, something like "If restricted indices are explicitly included in the names list, privileges will be checked against them regardless of the value of allow_restricted_indices" ?

[albertzaharovits]

Yes, good idea, I've amended the description as you suggested.

[albertzaharovits]

@elasticmachine run elasticsearch-ci/1

[albertzaharovits]

@elasticmachine run elasticsearch-ci/1

[albertzaharovits]

@elasticmachine run elasticsearch-ci/1

[albertzaharovits]

@elasticmachine run elasticsearch-ci/1

[albertzaharovits]

@elasticmachine run elasticsearch-ci/1