Cannot list or modify permissions on stack

[sathibault]

Description

The built-in admin user is not able to list or modify permissions on a stack. Both requests return 403. Also, users are able to see and create workspaces for a stack even though api/permissions/stack returns 404 implying they have no permissions.

Reproduction Steps

Request permissions on stack returns 404 as admin user:
{CHE_HOST}/api/permissions/stack?instance=java-default

Request permissions on stack/all returns 403 as admin user:
{CHE_HOST}/api/permissions/stack/all?instance=java-default&maxItems=30&skipCount=0

Post new permissions on stack returns 403 as admin user:
{CHE_HOST}/api/permissions
Body:
{"actions": [], "domainId": "stack", "instanceId": "java-default", "userId": "1cf13ce0-1338-47dc-b72f-114a369d2009"}

Ubuntu/Che 6.13.0

Diagnostics:

[sleshchenko]

Sorry for this unclear behavior but definitely should be improved.

So, by default admin does have permissions to do all operations with predefined stacks (remove, update, etc.) by he is not able to do any operation with their permissions.
Also, he is able to make any other stack public accessible:
POST http://che-che.192.168.99.100.nip.io/api/permissions

{"actions": ["search"], "domainId": "stack", "instanceId": "java-default", "userId": "*"}

Your admin will be able to do any operation with permissions you want after enabling super privileged mode for admins. It may be done with settings CHE_SYSTEM_SUPER__PRIVILEGED__MODE env var for Che Server. See https://www.eclipse.org/che/docs/che-6/permissions.html

Please ask if you need any additional information.

[sathibault]

With CHE_SYSTEM_SUPER__PRIVILEGED__MODE=true I am indeed able to see and update permissions on stacks I've created. However, the built-in stacks seems special in some way:

1. I still get the 403 responses described above
2. Even though a user has no permissions on them, they are listed and available to create workspaces.

[sathibault]

Accidentally, hit close button, but still have these issues with built-in stacks:

1. I still get the 403 responses described above
2. Even though a user has no permissions on them, they are listed and available to create workspaces.
3. Cannot delete built-in stacks

[sleshchenko]

@sathibault

2. Even though a user has no permissions on them, they are listed and available to create workspaces.

It's because search actions is granted for * user (means all users).

As about 1,3 - let me check on my installation and provide your more information.

[sleshchenko]

@sathibault

1. I still get the 403 responses described above

Request permissions on stack returns 404 as admin user:
http://cohort-api-server.test.multiscalehn.com:8080/api/permissions/stack?instance=java-default

It's OK even with super privileged mode since admin doesn't have direct permissions to predefined stacks.

Request permissions on stack/all returns 403 as admin user:
http://cohort-api-server.test.multiscalehn.com:8080/api/permissions/stack/all?instance=java-default&maxItems=30&skipCount=0

Admin should be able to use it but checked it on my Che installation and it does not work since Stack domain is not bound as super privileged. I think It's a bug and you can create a separate issue for that

Post new permissions on stack returns 403 as admin user: http://cohort-api-server.test.multiscalehn.com:8080/api/permissions
Body:
{"actions": [], "domainId": "stack", "instanceId": "java-default", "userId": "1cf13ce0-1338-47dc-b72f-114a369d2009"}

Do not work as well because of issue described above.
But setting the following permissions works fine

{"actions": ["search"], "domainId": "stack", "instanceId": "java-default", "userId": "*"}

3. Cannot delete built-in stacks

I successfully removed java-default and che7-preview stack. After that is disappeared from Stacks view on Dashboard {CHE_HOST}/swagger/#!/stack/removeStack
After restarting of Che Server they appear again. It's because of default value true for CHE_PREDEFINED_STACKS_RELOAD__ON__START. If you will set it to false then predefined stacks won't be recreated after Che Server restart.

[sathibault]

#3 is somehow working for me now. I did upgrade to 6.16.0, so maybe it was that.

It's probably worth documenting the fact that you can use "*" as the user ID in both POST /permissions and DELETE /permissions/{domain}.

[sleshchenko]

@sathibault

It's probably worth documenting the fact that you can use "*" as the user ID in both POST /permissions and DELETE /permissions/{domain}.

The corresponding issue to improve Che Docs is created #12482.
Feel free to reopen the issue if you think that any other issues should be registered according to problems you faced.