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

[Feature]: Complete Storage Authorization #1173

Open
2 tasks done
kkopanidis opened this issue Sep 25, 2024 · 1 comment
Open
2 tasks done

[Feature]: Complete Storage Authorization #1173

kkopanidis opened this issue Sep 25, 2024 · 1 comment
Labels
enhancement New feature or request
Milestone

Comments

@kkopanidis
Copy link
Contributor

Checklist

  • I agree to follow the Code of Conduct that this project adheres to.
  • I have searched the Issue Tracker for a feature request that matches the one I want to file, without success.

Suggestion

The storage module currently implements authorization optionally, and only for files. It needs to be expanded providing authorization in:

  • Container
  • Folder
  • File
@kkopanidis kkopanidis added the enhancement New feature or request label Sep 25, 2024
@kkopanidis kkopanidis added this to v0.17 Sep 25, 2024
@kkopanidis kkopanidis moved this to Todo in v0.17 Sep 25, 2024
@kkopanidis kkopanidis added this to the v0.17 milestone Sep 25, 2024
@ChrisPdgn
Copy link
Contributor

ChrisPdgn commented Jan 14, 2025

After some discussion we came up with the following:

  • Container, folder and file creation will result in an authz hierarchy tree, that mimics the filesystem structure. For example, a container X owns some folders (absolute paths), that each own some files. File creation API should adapt, so that no extra reconstructing job (like authz reconstruct indexes) is needed for projects that already use storage authorization

  • Upon file creation, we should check if user has permission for 'edit' action in given scope and also in given container and/or folder. To check the latter correctly, we should either:
    a) constrict users to create files only in shallow file paths
    b) find if the nested path is already stored in conduit and check access, otherwise find each subfolder and check access (I think we will come up with a better version of this solution)

  • Default container should not be owned

  • We should remove container creation logic from Client API

  • We will create personal user folders and use them as default when folder is not given in file creation

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
Status: Todo
Development

No branches or pull requests

2 participants