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 >>
