Hi, guys. for the pr: https://github.com/apache/openwhisk/pull/4058, the initial target is just `Add protect feature to avoid update or delete actions by mistake` It seems there has another option to do `granular permission management`, we can do it better. Below points is my new design for it. #### 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. 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 } ``` I also wrote it here: https://github.com/apache/openwhisk/pull/4058#issuecomment-851116337 Have any new idea or suggestion? -----Original Message----- From: "甯尤刚"<ning.youg...@navercorp.com> To: <dev@openwhisk.apache.org>; Cc: Sent: 2019/1/23周三 10:57 (GMT+08:00) Subject: [discuss]Add protect feature to avoid update or delete actions by mistake As more and more production system uses openwhisk, It seems we need some feature to protect their service safe from mistake. for example, 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 This is the patch: https://github.com/apache/incubator-openwhisk/pull/4058 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 So we can discuss there, is it necessary to add this feature? or any other suggestions.
