Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the auth capability for Tensorbase #268

Open
hsluoyz opened this issue Jul 16, 2021 · 4 comments
Open

Improve the auth capability for Tensorbase #268

hsluoyz opened this issue Jul 16, 2021 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@hsluoyz
Copy link
Member

hsluoyz commented Jul 16, 2021

We can provide more help for: tensorbase/tensorbase#126

@hsluoyz hsluoyz self-assigned this Jul 16, 2021
@hsluoyz hsluoyz added the enhancement New feature or request label Jul 16, 2021
@hsluoyz
Copy link
Member Author

hsluoyz commented Jul 16, 2021

@hackerchai @smrpn @PsiACE

@hackerchai
Copy link
Member

@hackerchai @smrpn @PsiACE

Will look into it

@frank-king
Copy link

frank-king commented Jul 25, 2021

Hi all, I'm the contributor of TensorBase, thank you for your interests of supporting TensorBase!

As the description in tensorbase/tensorbase#126,

Basically, we need two kinds of policies, which:

  1. describes which users have access to which databases/tables, in particular access patterns (e.g. read/write/update/...),
  2. describes which users have access to which computing resources, how many quotas, and the priorities.

we need two kinds of policies in our project. However, the problem is that casbin seems not to support multiple policies according to the descriptions on the doc.

In addition, the might be more problems where the actions might be composite. For example. If the user Bob submits a SQL to access the table school and teacher read only, running with 8 CPUs and 32 GiB memory, in a low priority. We will first check whether he has read access to the two tables, and how many quota of CPU and memory remained (owned by Bob).

Based on the current implementation of casbin, the above rules are possible to implement as:

  1. split up the two policies to two model files and policy files, and query the action separately;
  2. split up the access checks according to different tables (but it might become complicated if many tables are accessed in the same time, e.g. insert into A select ... from A join B join C will generate 4 actions: user read A, user write A, user write B, and user write C);
  3. maintain the usage of resources for users in runtime, and always query casbin with the total amount instead of the increment of currently-used resources (i.e., if Bob requested 4 CPUs and then 6 CPUs, Bob CPU 4, Bob CPU 10 will be generated)
  4. split up the access of different types of resources (similar to 2).

Do you have any better suggestions?


BTW, we prefer more meaningful field names such as

[policy_definition]
data = user, table, action
resource = user, type, quota, priority

instead of

[policy_definition]
p = sub, obj, act
p2 = sub. obj. act

Currently, those names seems to be hard-coded and not modifiable.

@hsluoyz
Copy link
Member Author

hsluoyz commented Jul 30, 2021

@smrpn

/cc @hackerchai

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants