For me, it makes sense to make generalized permission management. IIRC, PR 4058 is trying to bring the action protection feature by introducing a new annotation, "lock". But if we make a generalized version of it, it will cover PR 4058 case as well I think.
What I want to discuss is whether it would be enough to use "annotation" for permission management. If we use an annotation for permission management, we don't need any new kind of schema. If permission is specified in an annotation, EntitlementProvider will look into it when allowing access to an action. So when writing permission is disabled to protect the action, still, a user should be able to change the permission of the action. If we use annotation, it will be also stored in a database along with action data. It means we cannot update action data but can update the annotation. And it denotes a kind of logical notion change. It is easy to use annotation and doesn't require any new schema but it might be too naive. (Since I didn't contemplate it, not quite sure for now whether it will bring any negative ramification.) Another option is to bring a new schema into the scene such as a new request, new data, and so on. So the permission for an action will be configured aside from the action data. The EntitlementProvider will fetch new data to allow requests such as updating/invoking actions. So when a user wants to change the permission of an action, he is required to send a new form of request. And we need to define new REST APIs, new data format, new view(might be) and so on. Best regards Dominic 2019년 7월 9일 (화) 오후 4:45, Rodric Rabbah <rod...@gmail.com>님이 작성: > 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 > >>>> > >> > >> >
