Hello everyone: I reorganize the relevant content of this PIP. PTAL again. https://github.com/apache/pulsar/wiki/PIP-49:-Permission-levels-and-inheritance <https://github.com/apache/pulsar/wiki/PIP-49:-Permission-levels-and-inheritance>
In this PIP, I only fix the unreasonable permissions in the current command and shown in bold. About specific permission of command, if there are different opinions about this, pls let me know, thanks. -- Thanks Xiaolong Ran > 在 2019年11月8日，下午4:41，xiaolong ran <ranxiaolong...@gmail.com> 写道： > > Thanks Sijie, Joe F and Addison Highham feedback. > > As Joe said: > > > There are no simple answers here other than to understand the effect of the > > command. > > So in here, we can use sijie proposal, we only need to fix the unreasonable > permissions in the current command. > > I will reorganize this PIP, what do you think about this? > > -- > > Thanks > Xiaolong Ran > > >> 在 2019年11月8日，下午3:59，Sijie Guo <guosi...@gmail.com >> <mailto:guosi...@gmail.com>> 写道： >> >> If the problem is complex enough, can we first reduce the scope of this PIP >> to focus on fixing the permissions of individual commands (e.g. schemas >> don't require super-user permissions)? >> As you said, there is no simple answers. We can go through the commands one >> by one and come up a table of commands and their permissions and document >> it. >> It can help users understand how the permissions work for each command. >> >> We can revisit a larger scope till we add the capability of allocation >> resources at different levels. >> >> Does that make sense? >> >> - Sijie >> >> >> On Fri, Nov 8, 2019 at 3:22 PM Joe F <j...@apache.org >> <mailto:j...@apache.org>> wrote: >> >>> There are no simple answers here other than to understand the effect of the >>> command. >>> >>> The resource limit/control command always addresses an object. But giving >>> control of that command to the object owner, just because the command >>> addresses an object, will break all controls about resource utilization in >>> a shared system. A filesystem like model may look simple and elegant but >>> is fraught with all kind of unintended consequences if implemented in >>> Pulsar (Even in the filesystem rm, mv and chown, while all addressing a >>> file, treats the file owner differently) >>> >>> This is a complex, and complicated effort, and my concern is that this PIP >>> does not even come close to the scope of the work that is required. Some >>> of them may be impossible to do (as allocating certain resources to >>> namespace as compared to tenant) till such capabilities are added to the >>> system. And some begs fundamental questions - when you start managing a >>> namespace like a tenant, does it even make sense to have that namespace? >>> Should't that namespace be a tenant in the first place? Why have a >>> namespace admin at all? >>> >>> Joe >>> >>> >>> >>> On Thu, Nov 7, 2019 at 8:16 PM Dave Fisher <wave4d...@comcast.net >>> <mailto:wave4d...@comcast.net>> wrote: >>> >>>> I’m not diving in but thinking about the logical implication of this >>>> dichotomy. For any object’s attributes some ought to be controlled by >>>> object level permissions and others by sysadmin permissions. How can >>>> developers tell? >>>> >>>> Best Regards, >>>> Dave >>>> >>>> >>>> Sent from my iPhone >>>> >>>>> On Nov 7, 2019, at 8:02 PM, Joe F <j...@apache.org >>>>> <mailto:j...@apache.org>> wrote: >>>>> >>>>> This proposal has the same issues as the previous one . In general it >>> is >>>>> not correct to think of commands as being controlled by owner of the >>>>> object on which the command operates. Eg: It will be an error to >>> assing >>>>> control of all namespace commands to the namespace owner >>>>> >>>>> For eg: set subscription-dispatch-rate operates on a subscription rate >>>> and >>>>> set-max-producers-per-topic These operate on namespaces. A naive >>> approach >>>>> is to think that this would be controlled by the namespace owner. But >>>>> essentially both these are resource management operations. That should >>>> be >>>>> controlled by the system admin, unless you want to deal with every >>>>> namespace owner having the power to destroy your SLAs fo the cluster. >>>>> >>>>> I just picked 2 examples to indicate the drawback of approaching >>>>> permissions in the proposed manner. >>>>> >>>>> There are many such cases in the proposal, too many to list out here. I >>>>> suggest completely ditching this approach of equating objects with >>> admin >>>>> capability of object owner >>>>> >>>>> Joe >>>>> >>>>> >>>>>> On Wed, Nov 6, 2019 at 2:14 AM xiaolong ran <ranxiaolong...@gmail.com >>>>>> <mailto:ranxiaolong...@gmail.com> >>>> >>>>>> wrote: >>>>>> >>>>>> Hello all committers: >>>>>> >>>>>> About this PIP, do you have any other good ideas or propose. >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks >>>>>> Xioalong Ran >>>>>> >>>>>> >>>>>>>> 在 2019年10月30日，下午7:49，xiaolong ran <ranxiaolong...@gmail.com >>>>>>>> <mailto:ranxiaolong...@gmail.com>> 写道： >>>>>>> >>>>>>> Hello all: >>>>>>> >>>>>>> When using pulsar-admin, I found that the current permission >>>>>> verification mechanism has some problems. >>>>>>> >>>>>>> We are starting a proposal about permission levels and inheritance in >>>>>> Apache Pulsar. >>>>>>> >>>>>>> The proposal is in: >>>>>>> >>>>>> >>>> >>> https://github.com/apache/pulsar/wiki/PIP-49%3A-Permission-levels-and-inheritance >>> >>> <https://github.com/apache/pulsar/wiki/PIP-49%3A-Permission-levels-and-inheritance> >>>>>> < >>>>>> >>>> >>> https://github.com/apache/pulsar/wiki/PIP-49:-Permission-levels-and-inheritance >>>>>>> >>>>>>> >>>>>>> To ensure compatibility, these changes will be made in v4's admin >>> api. >>>>>> About the v4 admin API, see: >>>>>>> >>>>>>> >>> https://github.com/apache/pulsar/wiki/PIP-48%3A-hierarchical-admin-api >>>> < >>>>>> https://github.com/apache/pulsar/wiki/PIP-48:-hierarchical-admin-api> >>>>>>> >>>>>>> Looking forward to any feedback. >>>>>> >>>>>> >>>> >>>> >>> >
