DLS overrides broader permissions

[pgagnon]

Assume user1 has two roles (assume they are admin and read_index1_dls).

The admin role grants UNLIMITED permissions on * indices. The read_index1_dls role grants READ permissions on index1, but also restricts this user from seeing certain documents in index1 through a DLS query.

It would be expected that the user would have access to all documents in index1 through the admin role, however actual behavior is that the DLS query is applied, and user1 is unable to read documents that the DLS query filters.

As a side note, the search-guard documentation (see section Multiple roles and document-level security) states:

A user can be member of more than one role, and each role can potentially define a different DLS query for the same index. In this case, all DLS queries are collected and combined with OR.

So this actually might be expected behavior, however it is not "correct" from a usability standpoint, IMO.

[alolita]

@pgagnon Thanks for noting. Can you outline in more detail what your use case expects as correct behavior?

[pgagnon]

@alolita Thanks for your reply. I think that a grant on an index without an associated DLS query defined should be treated as if there was a DLS query defined that selected all documents. This way, when DLS queries are OR'ed to create the final filter (as described in the search-guard docs quoted above), all documents would be returned.

[shawnz]

I'm having the same issue. My setup is as follows: I have some users which are in the "all_access" role, and some users which are in the "[project name] developers" role. Some users are also in both roles. For those only with the project developer role, I restrict them to accessing only their project's logs using DLS. However for users who are in BOTH roles, I would expect that they are not restricted (since "all_access" would imply they can see all documents). However currently, the "all_access" users who are also "project developer" users experience the same restrictions as "project developer" users, i.e. they can only see logs for [project] and nothing else.

As a workaround I have created a new role "all_access_dls" which applies the following DLS query: { "match_all": {} }. Note that in order for this to work, I had specify the index patterns exactly the same as how they were specified in the other DLS roles. That is, I couldn't simply apply the "all_access_dls" role to index patterns matching "*", I had to manually specify that it should apply to index patterns matching "filebeat-*", same as my "project developer" role.

[thoro]

Same issue here, I would also expect if someone has all_access role without DLS applied, the defined dls for another role should be overwritten!

@shawnz Will try the work around, but that will make the queries obviously slower.

[shawnz]

Indeed, it made things very slow and we ended up dropping the DLS usage for now.

[hardik-k-shah]

Ideally, if user has two roles with different set of permissions, resultant permission will be always broader permissions.
Hence, in this case where all_access + other DLS restricted role, final permission should be resolved to all_access permission. We will further brainstorm this and come up with next steps to address this issue and update soon.

[chrousto]

Ideally, if user has two roles with different set of permissions, resultant permission will be always broader permissions.
Hence, in this case where all_access + other DLS restricted role, final permission should be resolved to all_access permission. We will further brainstorm this and come up with next steps to address this issue and update soon.

Hello,

I am in the process of coding a fix for this and will soon provide the community with a PR.
Christophe.

[cliu123]

@chrousto Thanks! Could you please link the PR to this issue?

[chrousto]

Hello it's not finished yet I have to test a couple of things first.

[chrousto]

@cliu123 I have created PR 1078, I don't see how to link it even though I have mentioned it in my commit.

[spapadop]

@hardik-k-shah is there an update on this? Seems like it slipped out of the radar.

[hardik-k-shah]

@spapadop thanks for tagging me. Checking it now.

[rursprung]

i think this is the same as i reported in #1572 (sorry, didn't spot your ticket at the time) and the solution for that has just been merged (see #1735).

[davidlago]

Thanks for connecting the two, @rursprung ! Closing the issue.