Request for Aligning Access Control in Enterprise Search Network Drive with Windows File Server

[m-amano]

Problem Description

We have identified two instances where the document access permissions in Elastic Search Applications differ from Windows behavior for network drive documents. In Elastic Search Applications, we use the Network Drive Connector Client for Access Control sync, and users log in with roles that have document-level access permissions based on the information in the "search-acl-filter-" prefixed index.

Issue 1: Write-only Permissions

Windows Behavior: Users with only write permissions for a document cannot retrieve or view the contents of that document.

Elastic Search Applications Behavior: The document appears in search results for these users.

Probable Cause: The condition at line 860 in the network_drive.py file lacks a check for read permissions. It doesn't exclude documents from the allow_permissions list when the user lacks read access.

Issue 2: Deny Permissions Override

Windows Behavior: If a user belongs to a group with read permissions for a document but is explicitly denied read access, they cannot open the file in File Explorer or view its contents using PowerShell's type command. This is because deny permissions always take precedence over allow permissions.

Elastic Search Applications Behavior: The document still appears in search results for these users.

Probable Cause: The deduplication process at line 714 in the network_drive.py file mixes user IDs and group IDs in the same list. After deduplication, even if the denied user's ID is removed, the allowed group ID remains. This results in behavior opposite to Windows' "deny permissions take precedence" rule.

Requested Changes

1. Modify the access control logic to check for read permissions before adding documents to the allow_permissions list.
2. Implement a mechanism to ensure that deny permissions take precedence over allow permissions, even when the allow permission comes from a group membership.

These changes would align the behavior of Enterprise Search's network drive document access control more closely with that of the Windows file server.

[seanstory]

@m-amano thanks for the really thorough issue! We're working on triaging and prioritizing this.

Changing to a "bug" since mistakes in DLS logic seem less negotiable.

[moxarth-rathod]

@m-amano @seanstory Second problem (Deny Permissions Override) in this issue seems duplicate of #1963 and #1966.
Already been fixed in this PR #2004.

Let us check the 1st problem (Write-only Permissions) from our end.

[moxarth-rathod]

Issue 2: Deny Permissions Override
Windows Behavior: If a user belongs to a group with read permissions for a document but is explicitly denied read access, they cannot open the file in File Explorer or view its contents using PowerShell's type command. This is because deny permissions always take precedence over allow permissions.
Elastic Search Applications Behavior: The document still appears in search results for these users.
Probable Cause: The deduplication process at line 714 in the network_drive.py file mixes user IDs and group IDs in the same list. After deduplication, even if the denied user's ID is removed, the allowed group ID remains. This results in behavior opposite to Windows' "deny permissions take precedence" rule.

@m-amano @seanstory looking at the cause, seems like it is not possible to fix this issue at the moment since we don't have a deny_access_control option to explicitly mention the denied permissions in the document.

In this PR, we even removed the users who has no READ permission from the allow_access_control list but group_id remains in the list. On the other hand, we can't even remove the user from the group o/w it may affect other documents.

[seanstory]

@m-amano @seanstory Second problem (Deny Permissions Override) in this issue seems duplicate of #1963 and #1966.
Already been fixed in this PR #2004.

Thanks @moxarth-elastic. @m-amano what version were you using when you observed these behaviors? The above-linked issue was fixed in 8.13.0 - can you try upgrading to that or later and see if that resolves the deny permissions override issue?

seems like it is not possible to fix this issue at the moment since we don't have a deny_access_control option to explicitly mention the denied permissions in the document.

This is a good point. We had this type of field in Workplace Search, but found it had never been utilized, and so did not include it here. I don't think it would be a massive amount of work to add it, though. CC @ioanatia in case you remember details here that I've forgotten.

@m-amano can you speak to how common this scenario is in your use case, where a user is in a group that is allowed access, but that user specifically has been denied? It seems like a more common approach would be to have more granular groups, no? CC @danajuratoni, we'll want to understand the customer benefit/need vs the effort to enhance our DLS logic.

[m-amano]

Thanks @moxarth-elastic. @m-amano what version were you using when you observed these behaviors? The above-linked issue was fixed in 8.13.0 - can you try upgrading to that or later and see if that resolves the deny permissions override issue?

@seanstory I checked with version v.8.15, and it seems that the behavior is the same as before. Even if user_a has read access denied, it appears that user_a can still read the document as long as the group they belong to has read permissions.

@m-amano can you speak to how common this scenario is in your use case, where a user is in a group that is allowed access, but that user specifically has been denied? It seems like a more common approach would be to have more granular groups, no? CC @danajuratoni, we'll want to understand the customer benefit/need vs the effort to enhance our DLS logic.

@seanstory This scenario is not very common. However, when there is sensitive information that should not be visible to specific users, it is essential to ensure that this information is reliably hidden. I believe that these restrictions should be enforced to protect confidential data.