Projects tigase _server server-core Issues #951
Improvements to ACL - limiting hard-checking permissions within ad-hoc scripts (#951)
Closed
wojciech.kapcia@tigase.net opened 6 years ago

Currently we have both ACL to control who should be able to execute scripts. And on top of that we perform additional validation within the scripts (mostly due to facilitate management of own domains by domain owners).

It would be best to limit amount of checking within the scripts. We could introduce additional ACL permission (e.g. DOMAIN_OWNER) which would allow execution of ad-hocs by domain owners. To maintain current limitations (i.e. domain owners my execute scripts, but they are limited to their own domains) we should expose configured ACL setting to the script and in case of scripts that differentiate functionality based on ownership of the domain determine that based on the configured ACL, i.e. if command is configured with DOMAIN_OWNER then it would work like now - owner would only be able to managed own domains and see user statistics from own domains, however if someone would configure ACL as LOCAL then all local users would be able to execute the script.

Basic idea is to allow configuring this with ACL configuration.

Please update documentation afterwards.

Andrzej Wójcik (Tigase) commented 6 years ago

I've made changes to the ACL adding DOMAIN_OWNER and DOMAIN_ADMIN values to give use fine-grained permissions checking (some commands should be executed only by owner and some by owner and admins).

I've updated most of the commands to use them by replacing calls to RepositoryItem::isAdmin() and RepositoryItem::isOwner() with call of a new lambda method which is passed in bindings called isAllowedForDomain. To use it just call isAllowedForDomain.apply(domain) and it will return true or false depending on user(caller) permissions for modifying items in the domain (result of checking ACLs).

If DOMAIN_OWNER or DOMAIN_ADMIN are not set (but other values are), calls to isAllowedForDomain are still safe to use and will result values which should be returned in those situations.

Please check if this works ok for you.

As for CompRepoItemUpdate and CompRepoItemRemove, I've left there checking based on items owner and admins values as it looked saner (not all items are domains so we should not make checking based on domains there).

wojciech.kapcia@tigase.net commented 6 years ago

Andrzej Wójcik wrote:

Please check if this works ok for you.

I've adjusted configuration of tigase-testsuite and it caught error in UserRosterManagement which I fixed. Other that that it works great - thank you.

As for CompRepoItemUpdate and CompRepoItemRemove, I've left there checking based on items owner and admins values as it looked saner (not all items are domains so we should not make checking based on domains there).

Makes sense.

Referenced from commit 11 months ago
issue 1 of 1
Type
New Feature
Priority
Normal
Assignee
RedmineID
7644
Version
tigase-server-8.0.0
Spent time
12h 30m
Issue Votes (0)
Watchers (0)
Reference
tigase/_server/server-core#951
Please wait...
Page is in error, reload to recover