Having access to the project role does not grant access to storage

[andriihomiak]

Having access to the project role does not grant access to storage

Context

If userA shares access to project by granting userB a project role, it is expected that userB will be able to upload data to the project volumes by running neuro-flow upload ALL.

Steps to reproduce

You'll need two user accounts - <userA> and <userB>

0. Create neuro-flow project from cookiecutter template

cookiecutter gh:neuro-inc/cookiecutter-neuro-project --checkout release

and update .neuro/ configs:

• set owner in project.yml to <userA>
• make sure every storage reference in volumes section of live.yml starts with storage:/$[[ project.owner ]]/$[[ flow.project_id ]]/

1. Login as<userA>
2. neuro-flow mkvolumes && neuro-flow upload ALL
3. neuro acl grant role://<userA>/projects/<project-id> <userB> write (<project-id> was specified when using cookiecutter template
4. Login as <userB>
5. neuro acl ls | grep <project-id> to confirm necessary permissions exist
6. neuro-flow -vv upload ALL

Expected behaviour

Upload succeeds

Actual behaviour

Following error is shown:

<TRUNCATED>
neuro_sdk.request: Fetch [POST] https://neu.ro/api/v1/users
neuro_sdk.request: Fetch [POST] https://neu.ro/api/v1/users/<userA>:projects:<project-id>/permissions
ERROR: neuro_flow.cli.main.main: Forbidden

[YevheniiSemendiak]

The problem might be in the root volume: https://github.com/neuro-inc/cookiecutter-neuro-project/blob/5c16c0893600fc1fd5159d9dfebce956e2b9b276/%7B%7Bcookiecutter.project_dir%7D%7D/.neuro/live.yml#L132
To overcome this issue, we could either check if the volume exists before trying to create it. Or try to create and if it fails with 403 - assume it already exists.

[johngull]

I would call it a serious security issue.

[YevheniiSemendiak]

Yes, the work-around of sharing the parent directory is a security issue.
Ping @romasku, could we tackle this issue?