New security features

[trofen]

I have a security-related requirement to provide different users with access to different peers within the same address book in RustDesk. Initially, I considered creating multiple separate address books, each containing only one peer, but that solution seems inefficient despite its feasibility.

Currently, I'm considering an idea consisting of two steps:

1. Implement access control directly on individual address book entries, similar to the existing access control mechanisms for entire address books.

2. Establish a many-to-many relationship between users and groups, allowing each user access to any quantity of groups.

@lejianwen, given your extensive experience with RustDesk, I'd greatly appreciate your thoughts or alternative suggestions regarding this approach. Additionally, are you aware of any potential RustDesk limitations that might prevent the successful implementation of such a scheme?

[lejianwen]

Are you talking about this feature?
The address book can be assigned to different users/groups

[trofen]

I want to have the same kind of access control on address book entries as on the address books themselves.

The idea is that address book entries should inherit access control settings from the address book itself, but also allow per-entry overrides.

For example:

• User1 and User2 are both members of Group1.
• Group1 has access to address book AB1.
• AB1 contains entries Peer1 and Peer2.
• By default, both users can access AB1 and its entries.
• But I want to restrict User2’s access to Peer2 with a specific rule defined directly on Peer2.

This way, general access is managed at the address book level, and fine-grained restrictions can be set per entry when needed.

What do you think about this approach? Do you see any potential issues with implementing it in RustDesk?

[lejianwen]

But I want to restrict User2’s access to Peer2 with a specific rule defined directly on Peer2.

API can implement this functionality
When a user retrieves My Address Book, the returned data can include these authorized entries, but there is no way to limit permissions(write/delete) in the client.

For example, if a user modifies a Peer but does not have permission(write/delete), the API should reject this operation. However, the interface cannot determine whether the user has permission.