Field and Document Level Security Limitations


#1

Hi all,

I've got a question regarding the security limitations: a normal user (even having all privileges to a particular index) cannot _update documents:

"type": "security_exception",
"reason": "Can't execute an update request if field or document level security is enabled"

But the super-user "elastic" account is able to _update anything!
The question: if the _update API is not supported with doc-level security, why the "superuser" role can update? And what kind of privileges should be given to a normal user (role) in order to be a "superuser" for a particular index?

Thanks!


(Jay Modi) #2

Can you provide more details? The superuser role grants access to everything and the role itself does not use document and field level security. The error message is a bit misleading but what it really means is if a user's permissions for an index contains a query (document level security) or field restrictions then we consider document and field level security enabled for this request so the user cannot use the update API.

Simply assign a role that grants all privileges to this index and do not specify a query or fields in the role.


#3

superuser role grants access to everything and the role itself does not use document and field level security.

I think, this is the key point, thank you for explaining that!

Could please clarify, when a role becomes a superuser role?

POST /_xpack/security/role/root
{
  "cluster": ["all"],  // (1)
  "indices": [
    {
      "names": [
        "*"            // (2)
      ],
      "privileges": [
        "all"          // (3)
      ],
	  "query": """
		{
			"template": {
			   "inline": "{ \"bool\" : { \"should\": [{ \"terms\": { \"user.roles.keyword\": {{#toJson}}_user.roles{{/toJson}} } }, { \"match\": { \"user.username.keyword\": \"{{_user.username}}\" } }] } }"
			}
		}
	  """	  
    }
  ],
  "run_as": ["*"],     // (4)
  "metadata": {},
  "transient_metadata": {
    "enabled": true
  }
}

(1) does not make the role a superuser
(3) for a single index (e.g. "names":["test"]) and for all indices (as above) - does not make the role a superuser-role
(4) does not make the role a superuser

Update request:

POST http://localhost:9200/test/t/1009/_update
{"doc":{"random": "111"}}

Response:

{
    "error": {
        "root_cause": [
            {
                "type": "security_exception",
                "reason": "Can't execute an update request if field or document level security is enabled"
            }
        ],
        "type": "security_exception",
        "reason": "Can't execute an update request if field or document level security is enabled"
    },
    "status": 400
}

Log:

[2017-02-08T08:13:06,883][DEBUG][o.e.x.s.a.l.LdapRealm    ] [host] authenticated user [sguy], with roles [[Domain Admins, Denied RODC Password Replication Group, root, Domain Users, Administrators, sales]]

So, how can a role be made a superuser role for a particular index?
Thank you!


(Jay Modi) #4

What do you mean by superuser role? Can you provide the output of GET /_xpack/security/role/root and GET /_xpack/security/role/sales

If you mean that the user has all privileges on a specific index:

{
  "indices": [
    {
      "names": [
        "*" 
      ],
      "privileges": [
        "all"
      ]
  ]
}

Notice that there is no query or fields key in the role.

If you mean for the whole cluster, then just use the superuser role that is provided.


#5

very good question! :slight_smile:
By superuser role I mean a role (not the built-in one!), that can do any changes on a particular index.

I guess, I got it finally - if a role with "priviliges: all" has a role query, when it won't be able to perform _update requests, right?
Thanks!


(Jay Modi) #6

Correct


(system) #7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.