Thanks Dominic for bringing up this feature. I know PR 4058 has been sitting for a while. Does it make sense to accept it (I will review it again it’s been a while since I posted my comments last) before going on to do more of the permissions work?
We should capture the dev list discussion in an issue. -r > On Jul 6, 2019, at 1:49 AM, Dominic Kim <style9...@gmail.com> wrote: > > Thank you for the good point, Martin. > I will take it into account. > > Best regards > Dominic > > > 2019년 7월 5일 (금) 오후 10:10, Martin Henke <martin.he...@web.de>님이 작성: > >> Dominic, >> >> I would very much like to have this change introduced in a backward >> compatible fashion. >> >> In Detail: >> The default permissions should either keep the same behaviour as with the >> current code >> or better be configurable via Ansible in a way that he system behaves the >> same as before. >> If you decide for a schema change, the code should be handle existing >> actions with the existing behaviour. >> >> With being backward compatible there would be no need to introduce this >> change in a new EntitlementProvider implementation but can (and should) >> be placed in the (default) LocalEntitlement provider to have consistent >> code in the default configuration for Action creation (adding the access >> rights) and entitlement checking (reading the access rights). >> >> Thank you for driving this forward., >> Martin >> >> >> >>> On 4. Jul 2019, at 17:12, Dominic Kim <style9...@gmail.com> wrote: >>> >>> Thank you for the feedback, James. >>> >>> I am thinking of implementing it with annotations. >>> For example, we would add a new annotation reserved by the system. >>> When an action is created, the default permission will be specified via >> the >>> annotation. >>> >>> When any request comes, a new EntitlementProvider will look for the >>> annotation and reject the request based on it. >>> >>> This is to minimize the action schema change. >>> But if it's ok to bear with the schema change, I am ok with adding one >> more >>> field in an action other than annotations or parameters. >>> >>> 2019년 7월 4일 (목) 오후 10:07, James Thomas <jthomas...@gmail.com>님이 작성: >>> >>>> Protecting accidental overwritting or deletion of actions would be a >> great >>>> feature. I like the suggestion and approach of using Unix-style >>>> permissions. >>>> >>>>> On Thu, 4 Jul 2019 at 07:25, Dominic Kim <style9...@gmail.com> wrote: >>>>> >>>>> Recently I discussed this: >>>>> https://github.com/apache/incubator-openwhisk/pull/4058 with my >>>>> colleagues. >>>>> That PR is to add a feature to protect actions from deletion by >> mistake. >>>>> That is a good suggestion and I think we can also include more >>>> generalized >>>>> way to handle the issue. >>>>> >>>>> For example, what we can expect about permission are as follows. >>>>> >>>>> 1. Action protection. >>>>> 2. Hide codes from the shared package. >>>>> >>>>> I am a bit faint but IIRC, Rodric suggested linux-like permission >>>>> management. >>>>> >>>>> Regarding number 1, we can achieve it with the permission, "Read / not >>>>> Write / Execute". >>>>> And with regared to number 2, we can also achieve it with the >> permission, >>>>> "not Read / not Write (this is the default of shared package action) / >>>>> Execute". >>>>> >>>>> If we apply linux-like permission to these cases, we can have two >>>> different >>>>> permission flags, one for owners, the other for users of shared >> packages. >>>>> Then actions can have permission information such as "71" or "51". >>>>> So "71" would mean the owner of an action can do "read/write/execute" >> it >>>>> but the one who uses the shared action would be able to do "not >> read/not >>>>> write/execute". >>>>> "51" would mean the owner can do "read/not write/execute". >>>>> >>>>> There might be more cases, but I believe we can deal with them in the >>>> same >>>>> way. >>>>> Any feedback or idea on this would be appreciated. >>>>> >>>>> Thanks >>>>> Best regards, >>>>> Dominic >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> James Thomas >>>> >> >>
