Add protect feature to avoid update or delete actions by mistake #4058

ningyougang · 2018-10-08T09:54:05Z

As more and more production system uses openwhisk,
Users will need some features to protect their service safe from mistake.
If we have this feature, user can protect their actions from deletion by mistake.

When users create action use like below(add annotation "lock":true)

curl  -X PUT -H "Content-type: application/json"  --user 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP 
-d '{"namespace":"guest","name":"hello","annotations":[{"key":"lock","value":true}],"exec":{"kind":"nodejs:default","code":"// Licensed to the Apache Software Foundation (ASF) under one or more contributor\r\n// license agreements; and to You under the Apache License, Version 2.0.\r\n\r\n/**\r\n * Hello, world.\r\n */\r\nfunction main() {\r\n return {\"payload\":\"Hello world\"};\r\n}\r\n"}}' 
'http://xxx.xxx.xxx.xxx:port/api/v1/namespaces/guest/actions/hello?'

The lock field will be added in couchdb's annotation, like below

...
  "annotations": [
    {
      "key": "exec",
      "value": "nodejs:6"
    },
    {
      "key": "lock",
      "value": true
    }
...

So this action can't be deleted/updated until the protection is updated to false

Description

Related issue and scope

I opened an issue to propose and discuss this change (#????)

My changes affect the following components

Types of changes

Bug fix (generally a non-breaking change which closes an issue).
Enhancement or new feature (adds new functionality).
Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

I signed an Apache CLA.
I reviewed the style guides and followed the recommendations (Travis CI will check :).
I added tests to cover my changes.
My changes require further changes to the documentation.
I updated the documentation where necessary.

cbickel

Hi,

thanks a lot for your contribution. This PR definitely makes sense.

You are adding the protection-parameter as URL parameter. What's the reason for doing it like this?
Today: Everything that is a property of the action is within WhiskActionPut. The overwrite parameter only says, that this request should overwrite the action if it already exists.
IMHO the protection parameter is a property of the action itself and not of that request.

And a second thought that comes into my mind: If we protect the action, should it only be protected against deletion? Or would it make sense to protect it against updates as well? (The trick here would be to allow the update to unlock the action again).

I don't know what your thoughts on these two issues are. If your thoughts are completely different mybe it makes sense to ask the dev-list, if someone has a strong opinion on these two questions on the dev-list.

core/controller/src/main/scala/whisk/core/controller/Actions.scala

rabbah · 2018-10-08T15:11:45Z

This is a good start but we should discuss and settle the design first. For example my preference is for Unix style permissions on the action (or asset more generally).

ningyougang · 2018-10-09T02:00:51Z

@cbickel @rabbah ,thanks for your quick reply.

Actually, i opened a pr first here: apache/openwhisk-cli#372
Solve the update/delete mistake on CLI side, after think deeply, i found, it is better to solve it in backend layer.(So don't merge that pull/372 temporarily)

I did below changes

Add "annotations":[{"key":"lock","value":true}] to body instead of URL request param

So we can use below method to protect the action when created or updated

curl  -X PUT -H "Content-type: application/json"  
--user 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP 
-d '{"namespace":"guest","name":"hello","annotations":[{"key":"lock","value":true}],
"exec":{"kind":"nodejs:default","code":"// Licensed to the Apache Software Foundation (ASF) under one or more contributor\r\n// license agreements; and to You under the Apache License, Version 2.0.\r\n\r\n/**\r\n * Hello, world.\r\n */\r\nfunction main() {\r\n return {\"payload\":\"Hello world\"};\r\n}\r\n"}}' 
'/api/v1/namespaces/guest/actions/hello?overwrite=true'

Or use wsk like this wsk action create hello hello.js --annotation lock true

Or would it make sense to protect it against updates as well?

I agree, already added
The trick here would be to allow the update to unlock the action again

Use below method(pass -d '{"unlock:"true"}'), for example

curl  -X PUT  -H "Content-type: application/json"  
--user 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP 
-d '{"unlock":"true"}'  'http://xxx.xxx.xxx.xxx:port/api/v1/namespaces/guest/actions/hello?overwrite=true'

After executed above method, this action enabled updated or deleted operation

Wsk side(TODO)

If this patch is merged into upstream, the wsk side will do some changes, add unlock feature to wsk to enable update or delete operation, for example

wsk action update hello --unlock

codecov-io · 2018-10-11T08:50:17Z

Codecov Report

Merging #4058 into master will decrease coverage by 7.59%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master    #4058     +/-   ##
=========================================
- Coverage   86.21%   78.61%   -7.6%     
=========================================
  Files         152      153      +1     
  Lines        7275     7895    +620     
  Branches      477      518     +41     
=========================================
- Hits         6272     6207     -65     
- Misses       1003     1688    +685

Impacted Files	Coverage Δ
...org/apache/openwhisk/core/entity/WhiskAction.scala	`86.82% <100%> (+0.07%)`	⬆️
...org/apache/openwhisk/core/controller/Actions.scala	`93.48% <100%> (+0.31%)`	⬆️
...rg/apache/openwhisk/core/controller/ApiUtils.scala	`77% <100%> (+3.43%)`	⬆️
...core/database/cosmosdb/RxObservableImplicits.scala	`0% <0%> (-100%)`	⬇️
...n/scala/org/apache/openwhisk/common/CausedBy.scala	`0% <0%> (-100%)`	⬇️
...core/database/cosmosdb/CosmosDBArtifactStore.scala	`0% <0%> (-95.54%)`	⬇️
...sk/core/database/cosmosdb/CosmosDBViewMapper.scala	`0% <0%> (-92.6%)`	⬇️
...whisk/core/database/cosmosdb/CosmosDBSupport.scala	`0% <0%> (-83.34%)`	⬇️
...abase/cosmosdb/CosmosDBArtifactStoreProvider.scala	`3.44% <0%> (-59.06%)`	⬇️
...penwhisk/core/database/cosmosdb/CosmosDBUtil.scala	`57.5% <0%> (-38.5%)`	⬇️
... and 20 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cb02bdb...63a2aaf. Read the comment docs.

core/controller/src/main/scala/org/apache/openwhisk/core/controller/Actions.scala

rabbah · 2019-01-24T15:55:00Z

Sorry for taking so long to get through this --- taking a look now it's a good first step but i think it points to a more general permission set on an action: this is an write permission for the namespace (group in unix terminology), and one can image an execute permission as well next (disables an action from executing for a namespace).

So one of my thoughts is whether to factor the permission more generally to allow for generalization later... or leave it as is and change it later.

Thoughts?

ningyougang · 2019-01-28T02:15:28Z

@rabbah
Regarding factor the permission more generally
it is a good suggestion, let's leave it as is and change it later.

At the same time, we can wait other upsteam guys to give more suggestions,
if we agree on the idea, go on to do this.

mhenke1 · 2019-01-28T12:12:14Z

@ningyougang
Sorry for joining late in this discussion.
In my last year I have implemented the SPIs for plugging in alternative Authentication and Entitlement providers in Openwhisk. My strong suggestion would be to place any additional code checking for entitlement (in this case: the entitlement to delete entities) into the existing entitlement SPI implementation.
Alternative entitlement implementations (like the one I have implemented for IBM cloud functions) might prevent accidental deletion in other ways like configuring user or user group specific polices
in a policy system. They have no need of additional protection.
Of course the default entitlement provider would benefit from a mechanism like the one you proposed. By moving the functionality in the Entitelemnt-SPI the functionality could be added to the default path, but would not interfere with alternative entitlement implementations.

rabbah · 2019-01-28T12:27:12Z

@mhenke1 Are the alternatives you've implemented something that is planned for open source contribution?

rabbah · 2020-04-22T14:15:14Z

docs/actions.md

@@ -598,6 +598,28 @@ You can clean up by deleting actions that you do not want to use.
  actions
  /guest/mySequence                private sequence
  ```
+## Protect action updated or deleted by mistake


I will suggest some updates to this text once the API change and implementation are finalized.

Updated accordingly

ningyougang · 2020-05-11T10:07:56Z

Hi, guys, i push a temp commit here in this patch, just check my direction(permission unix sytle) is whether right. d77a80f

After check in my local, i found that, there has some differences between our own permission management between unix permission management.

1. user type is different

for one action, just have 2 type users.

the action's owner
the user (not the owner) who used the shared action directly(eg. get, invoke)

As we all already know, unix's permission has 3 user types, this is the different point.

2. our own permission value is restricted

for one action, anyway, the user(not the owner) can't modify/delete the action on any situation, just the owner has the write permission.
the owner's permission can affect the permission as well, e.g. if the owner is not given read permission, i think the user(not the owner) can't have read permission as well. if the owner is not give execute permission, the user(not the owner) can't have execute permission as well.

How do you guys think?

jiangpengcheng · 2020-05-13T09:54:56Z

common/scala/src/main/scala/org/apache/openwhisk/core/entity/WhiskAction.scala

+  // 4. permission code:r-xr--: owner:read(yes)/write(no)/execute(yes)|the shared action's user:read(yes)/write(no)/execute(no)
+  // 5. permission code:r--r--: owner:read(yes)/write(no)/execute(no)|the shared action's user:read(yes)/write(no)/execute(no)
+  // 6. permission code:rw-r--: owner:read(yes)/write(yes)/execute(no)|the shared action's user:read(yes)/write(no)/execute(no)
+  val permissionList = List(defaultPermissions, "rwxr--", "r-xr-x", "r-xr--", "r--r--", "rw-r--")


does r means get codes here?

for the shared user, the r means download the code

ningyougang · 2020-09-08T07:43:39Z

core/controller/src/main/scala/org/apache/openwhisk/core/entitlement/Entitlement.scala

+          case t: RejectRequest =>
+            Future.failed(t)
+          case _ =>
+            Future.successful(())


In order to make some test cases successfully .e.g

./gradlew :tests:test --tests="org.apache.openwhisk.core.controller.test.PackageActionsApiTests" ./gradlew :tests:test --tests="org.apache.openwhisk.core.controller.test.ActionsApiTests"

Need to add above recoverWith logic, concrete content is

if the excpetion is RejectRequest, return Future.failed(t)

make normal logic passed

For some excpetion which generated by test above cases, should return Future.successful(())

Make above tests cases passed, e.g. https://github.com/apache/openwhisk/blob/master/tests/src/test/scala/org/apache/openwhisk/core/controller/test/PackageActionsApiTests.scala#L130
here, it will pass a package paramter to get(entityStore, entityName.toDocId, DocRevision.empty, true)'s second param, actually, this method needs action, so will throw NoDocument exception, in order to make the test case passed, need to make it return Future.successful(())

ningyougang · 2020-09-09T01:07:38Z

Already rebased and solved relative test cases error

style95 · 2020-09-29T04:52:30Z

common/scala/src/main/scala/org/apache/openwhisk/core/entity/WhiskAction.scala

+
+  val defaultPermissions = "rwxr-x"
+
+  // notes on users, just have 2 type users,


I'd rather keep this information in some markdown file and just leave the link here.

Updated accordingly.

style95 · 2020-09-29T04:56:21Z

common/scala/src/main/scala/org/apache/openwhisk/core/entity/WhiskAction.scala

+    "rwxr--",
+    "r-xr-x",
+    "r-xr--",
+    "r--r--",


Is there any case where an owner does not need to either update or execute the action?
If so, how can the user update the action permission and the action itself?

Yes, there has an case that the owner doesn't have permission to update or execute the action, e. g. the annotation of permission for that action is: r--r--
in this case, if the owner wants to update the action codes, need to modify the action's permissions annotation to executeable, e.g. wsk -i action update $action --annotation permissions rw-r--, then, user can update their action now.

So even if an owner doesn't have any permission, he can still update the permission annotations?

style95 · 2020-09-29T04:58:32Z

common/scala/src/main/scala/org/apache/openwhisk/core/entity/WhiskAction.scala

+  // 10. permission code:r-x---: owner:read(yes)/write(no)/execute(yes)|the shared action's user:download(no)/write(no)/execute(no)
+  // 11. permission code:r-----: owner:read(yes)/write(no)/execute(no)|the shared action's user:download(no)/write(no)/execute(no)
+  // 12. permission code:rw----: owner:read(yes)/write(yes)/execute(no)|the shared action's user:download(no)/write(no)/execute(no)
+  val permissionList = List(


I'd apply a regex match to confirm the permission value rather than just checking the existence of the value in a list.

style95 · 2020-09-29T05:01:42Z

common/scala/src/main/scala/org/apache/openwhisk/core/entity/WhiskAction.scala

@@ -351,6 +361,49 @@ object WhiskAction extends DocumentFactory[WhiskAction] with WhiskEntityQueries[
  val execFieldName = "exec"
  val requireWhiskAuthHeader = "x-require-whisk-auth"

+  // annotation permission key name
+  val permissionsFieldName = "permissions"


I am not quite sure it is a good idea to use annotations for permission management.
I feel like we need a new protocol.

yes, i also feel it is not a good idea to use annotation for permission management.
Currently, have no better idea for it.

I think we can store permission information in DB and fetch it along with Identity information.
Some proper tools to manage permission are required and the same change should be applied in CLI(wsk or at least wskadmin) as well.

I think such permission information is applied to actions instead of Identity

I meant, we can fetch the permission information in a similar way with Identity.
This information can be stored in the cache too.
Permission needs to be checked before actual operations.

style95 · 2021-05-24T05:54:42Z

core/controller/src/main/scala/org/apache/openwhisk/core/entitlement/Entitlement.scala

+      get(entityStore, entityName.toDocId, DocRevision.empty, true)
+        .flatMap { whiskAction =>
+          val currentPermissions = whiskAction.annotations
+            .get(WhiskAction.permissionsFieldName)


We can depend on permission data in DB rather than relying on action fields.

jiangpengcheng · 2021-05-26T03:28:05Z

core/controller/src/main/scala/org/apache/openwhisk/core/entitlement/Entitlement.scala

+              } else {
+                val passedUpdatePermission = value.charAt(1)
+                if (passedUpdatePermission == 'w') { // make it to modifiable
+                  Future.successful(())


so once passed a w of action permission in params, the update will always pass priviledge checking even old update permission is -?

Yes, you are right. e.g.

# wsk -i action create hello ~/hello.js --annotation permissions r-xr-x ok: created action hello # wsk -i action update hello ~/hello.js error: Unable to create action 'hello': have no permission to update this action (code iAKv0FTZLaURFtLzoSzryZhLpemxDell) # wsk -i action update hello ~/hello.js --annotation permissions rwxr-x ok: updated action hello

jiangpengcheng · 2021-05-26T03:29:01Z

core/controller/src/main/scala/org/apache/openwhisk/core/entitlement/Entitlement.scala

+    entityName: FullyQualifiedEntityName,
+    get: (ArtifactStore[WhiskEntity], DocId, DocRevision, Boolean) => Future[WhiskAction],
+    permissions: Option[String] = None)(implicit transid: TransactionId): Future[Unit] = {
+    if (operation == "create") {


I think

operation match { case "create" => ...

should be better

Updated accordingly.

jiangpengcheng · 2021-05-26T03:34:34Z

core/controller/src/main/scala/org/apache/openwhisk/core/entitlement/Entitlement.scala

+            .getOrElse(WhiskAction.defaultPermissions)
+
+          val errorInfo = s"have no permission to download this shared action"
+          val currentDownloadPermission = currentPermissions.charAt(3)


shouldn't this be currentPermissions.charAt(0)? since permission string is like rwx--- and the first char indicate the "read" permission

It is for the shared user, so currentPermissions.charAt(3) is right.
If the user is owner, the owner has download permission on any situation

hm...anyway, you said problem is also a problem, it is not readable. i will optimize the codes like below

if (user.namespace.name.asString != entityName.path.root.asString) { // the shared user who download the action val errorInfo = s"have no permission to download this shared action" val downloadPermissionOfSharedUser = currentPermissions.charAt(3) if (downloadPermissionOfSharedUser == '-') { Future.failed(RejectRequest(Forbidden, Some(ErrorResponse(errorInfo, transid)))) } else { Future.successful(()) } } else { // the owner has download permission on any situation Future.successful(()) }

jiangpengcheng · 2021-05-26T03:38:41Z

one of my thought is that there is no need to add permissions controls for action's "owner" since he/she can anyway update/remove/invoke his/her action

- As more and more production system uses openwhisk, Users will need some features to protect their service safe from mistake. If we have this feature, user can protect their actions from updating or deletion by mistake. - Apply unix style permission management - Make the action's downloadable for the shared user

codecov-commenter · 2021-05-28T09:15:52Z

Codecov Report

Merging #4058 (92b2a38) into master (b818c3b) will decrease coverage by 1.46%.
The diff coverage is 90.62%.

@@            Coverage Diff             @@
##           master    #4058      +/-   ##
==========================================
- Coverage   77.26%   75.80%   -1.47%     
==========================================
  Files         219      226       +7     
  Lines       11205    11578     +373     
  Branches      487      498      +11     
==========================================
+ Hits         8658     8777     +119     
- Misses       2547     2801     +254

Impacted Files	Coverage Δ
...cala/org/apache/openwhisk/http/ErrorResponse.scala	`89.79% <ø> (+2.04%)`	⬆️
...pache/openwhisk/core/entitlement/Entitlement.scala	`83.67% <86.66%> (+1.85%)`	⬆️
...org/apache/openwhisk/core/controller/Actions.scala	`90.90% <94.11%> (+0.12%)`	⬆️
...org/apache/openwhisk/core/entity/WhiskAction.scala	`93.06% <100.00%> (+0.71%)`	⬆️
...core/database/cosmosdb/RxObservableImplicits.scala	`0.00% <0.00%> (-100.00%)`	⬇️
...ore/database/cosmosdb/cache/CacheInvalidator.scala	`0.00% <0.00%> (-100.00%)`	⬇️
...e/database/cosmosdb/cache/ChangeFeedConsumer.scala	`0.00% <0.00%> (-100.00%)`	⬇️
...core/database/cosmosdb/CosmosDBArtifactStore.scala	`0.00% <0.00%> (-95.85%)`	⬇️
...sk/core/database/cosmosdb/CosmosDBViewMapper.scala	`0.00% <0.00%> (-93.90%)`	⬇️
...tabase/cosmosdb/cache/CacheInvalidatorConfig.scala	`0.00% <0.00%> (-92.31%)`	⬇️
... and 49 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b818c3b...92b2a38. Read the comment docs.

ningyougang · 2021-05-31T02:01:35Z

According to review comments

It seems there has another option to do granular permission management

1. There is no need to add permissions controls for action's "owner" since he/she can anyway update/remove/invoke his/her action

2. It is necessary to control other shared user's permission (e.g. whether has permission to read/download the codes, whether has permission to execute the codes), this separate document in db: `xxx_permission` may like below

{
  "_id": "whisk.system/helloAction",
  "_rev": "1-1a14818c1083bc12b6d3fd1774fcc956",
  "default": {
      {
           "read" : false
           "execute": false
      }
   }
  "permission": {
      "theSharedUserA": {
           "read" : yes
           "execute": yes
      },
      "theSharedUserB": {
           "read" : yes
           "execute": false
      }
  }

Regarding above permission document of whisk.system/helloAction

when create action: whisk.system/helloAction, the owner can set default read/execute permission for all shared user. e.g.

  "default": {
      {
           "read" : false
           "execute": false
      }
   }

the shared user will inherits the default permissions if not explicitly specified in above document. e.g.

not explicitly specified for theSharedUserC, so theSharedUserC will have default permission

if explicitly specified in above document for the shared user, the shared user will have specified permission, e.g.

already explicitly specified for theSharedUserA, so theSharedUserA's permission is

      "theSharedUserA": {
           "read" : yes
           "execute": yes
      }

ningyougang · 2021-06-10T06:59:30Z

@style95 ,

Current system permission already existed design solution:

the owner have any permissions(read/update/execute) for this own actions.
if a package is binded to a shared package, all users except the owner(we call it shared users) just have read/execute permission for that shared package's actions but do not have update permission.
if package is not binded to any package, all users(except the owner) do not have any permissions(e.g. read/update/execute) for that package's actions

New design solution: #4058 (comment)

The difference between the new design solution and the current system design is:

the new design solution can control every shared user's permission

hm..actually, for now, i don't know what's the direction of this pr.

style95 · 2023-05-20T21:41:18Z

@ningyougang Sorry for the late response.
I want to check if we can continue this PR again.

csantanapr requested review from dubee and cbickel October 8, 2018 13:36

cbickel requested changes Oct 8, 2018

View reviewed changes

core/controller/src/main/scala/whisk/core/controller/Actions.scala Outdated Show resolved Hide resolved

core/controller/src/main/scala/whisk/core/controller/Actions.scala Outdated Show resolved Hide resolved

ningyougang mentioned this pull request Oct 9, 2018

Add confirm mechanism when delete or update action apache/openwhisk-cli#372

Open

ningyougang force-pushed the add-protection-to-action branch from 3b7a7ed to d95dfce Compare October 11, 2018 08:02

ningyougang changed the title ~~Add protect feature to avoid delete actions by mistake~~ Add protect feature to avoid update or delete actions by mistake Oct 11, 2018

ningyougang force-pushed the add-protection-to-action branch from d95dfce to 5356f5a Compare October 11, 2018 09:10

ningyougang mentioned this pull request Oct 19, 2018

[Feature requests] action protection #3629

Open

rabbah self-requested a review November 10, 2018 20:05

rabbah added controller review Review for this PR has been requested and yet needs to be done. labels Nov 10, 2018

ningyougang closed this Dec 24, 2018

ningyougang reopened this Dec 24, 2018

ningyougang force-pushed the add-protection-to-action branch from 5356f5a to 63a2aaf Compare January 7, 2019 02:38

ningyougang closed this Jan 7, 2019

ningyougang reopened this Jan 7, 2019

ningyougang closed this Jan 21, 2019

ningyougang reopened this Jan 21, 2019

dubee reviewed Jan 23, 2019

View reviewed changes

core/controller/src/main/scala/org/apache/openwhisk/core/controller/Actions.scala Outdated Show resolved Hide resolved

ningyougang force-pushed the add-protection-to-action branch 3 times, most recently from 546f431 to 69602d9 Compare January 24, 2019 05:34

rabbah self-assigned this Jan 24, 2019

rabbah reviewed Apr 22, 2020

View reviewed changes

ningyougang force-pushed the add-protection-to-action branch from 69602d9 to d77a80f Compare May 11, 2020 09:57

ningyougang force-pushed the add-protection-to-action branch 2 times, most recently from cf35509 to 1c37112 Compare May 13, 2020 09:49

jiangpengcheng reviewed May 13, 2020

View reviewed changes

ningyougang force-pushed the add-protection-to-action branch from 1c37112 to 4af70b8 Compare June 8, 2020 08:59

style95 mentioned this pull request Jul 28, 2020

Execute Only for Shared Actions #4935

Merged

12 tasks

ningyougang force-pushed the add-protection-to-action branch from 4af70b8 to db02599 Compare September 7, 2020 02:31

ningyougang commented Sep 8, 2020

View reviewed changes

ningyougang closed this Sep 8, 2020

ningyougang reopened this Sep 8, 2020

style95 reviewed Sep 29, 2020

View reviewed changes

ningyougang force-pushed the add-protection-to-action branch from 4367a2c to a7a51d9 Compare October 14, 2020 05:38

style95 reviewed May 24, 2021

View reviewed changes

jiangpengcheng reviewed May 26, 2021

View reviewed changes

ningyougang added 5 commits May 28, 2021 11:08

Fix test cases error

b9a8ca8

Fix review points

c00f5f6

Optimize the download code for shared user readable

51ca755

Change from if/else to match/case statement

92b2a38

ningyougang force-pushed the add-protection-to-action branch from a7a51d9 to 92b2a38 Compare May 28, 2021 06:22


		val defaultPermissions = "rwxr-x"

		// notes on users, just have 2 type users,

Add protect feature to avoid update or delete actions by mistake #4058

Are you sure you want to change the base?

Add protect feature to avoid update or delete actions by mistake #4058

Conversation

ningyougang commented Oct 8, 2018 • edited by rabbah

Description

Related issue and scope

My changes affect the following components

Types of changes

Checklist:

cbickel left a comment

Choose a reason for hiding this comment

rabbah commented Oct 8, 2018

ningyougang commented Oct 9, 2018 • edited

codecov-io commented Oct 11, 2018 • edited

Codecov Report

rabbah commented Jan 24, 2019

ningyougang commented Jan 28, 2019

mhenke1 commented Jan 28, 2019

rabbah commented Jan 28, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ningyougang commented May 11, 2020 • edited

1. user type is different

2. our own permission value is restricted

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ningyougang commented Sep 9, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

style95 May 20, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ningyougang May 28, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ningyougang May 28, 2021 • edited

Choose a reason for hiding this comment

jiangpengcheng commented May 26, 2021

codecov-commenter commented May 28, 2021 • edited

Codecov Report

ningyougang commented May 31, 2021 • edited

1. There is no need to add permissions controls for action's "owner" since he/she can anyway update/remove/invoke his/her action

2. It is necessary to control other shared user's permission (e.g. whether has permission to read/download the codes, whether has permission to execute the codes), this separate document in db: xxx_permission may like below

ningyougang commented Jun 10, 2021 • edited

style95 commented May 20, 2023 • edited

ningyougang commented Oct 8, 2018 •

edited by rabbah

ningyougang commented Oct 9, 2018 •

edited

codecov-io commented Oct 11, 2018 •

edited

ningyougang commented May 11, 2020 •

edited

style95 May 20, 2023 •

edited

ningyougang May 28, 2021 •

edited

ningyougang May 28, 2021 •

edited

codecov-commenter commented May 28, 2021 •

edited

ningyougang commented May 31, 2021 •

edited

2. It is necessary to control other shared user's permission (e.g. whether has permission to read/download the codes, whether has permission to execute the codes), this separate document in db: `xxx_permission` may like below

ningyougang commented Jun 10, 2021 •

edited

style95 commented May 20, 2023 •

edited