Hi Mihail, Thanks for taking the time to read this and give feedback. Much appreciated.
On 28/10/2014 12:02, "Mihail, StanciuX" <[email protected]> wrote: >Hello Belén, > >While I agree with your assessment in general, there is one possible >problem I foresee: >If I understand it right, in the distributed approach anyone can create a >new project whenever they want to. >While this shouldn't be a problem under normal working conditions for a >small to medium user base, I feel that for a public implementation or a >very large user base this might present a resource problem in that, due >to a large number of active projects, queues might grow to become far too >large for normal use. >By extension, I think this might also be a vulnerability for malicious >users to exploit. > >If I might suggest a hybrid of the two approaches, as follows: > >3. The Hybrid >Basically, this is a distributed approach, with an additional layer on >top - a moderately powerful administrator that grants project-creation >rights to users, as needed. Well spotted: my email made no mention to the permissions system. I think the plan is to put in place very simple permissions initially, mainly to make sure we hit our 1.8 target. The permissions you can grant a user will be something like: * Access to a project, which is binary (i.e. If you have access, you can see the configuration and the build information, you can download artifacts, you can change the configuration and you can start builds) * Creating projects, which is also binary (either you can create new Toaster projects or you can't). * Administering Toaster: this gives a user the ability to access and edit the Toaster configuration using the Django admin interface. >This way I feel we maintain most of the benefits of the distributed >approach, as opposed to the top-down approach, but with the added >security of not allowing just anyone who gets access to the toaster >server to create a project and request resources without some >supervision, be it from the "administrator" that granted them project >creation rights or the project owner that granted them access to their >project. > >Of course, I just might be overly paranoid :) I think you are not overly paranoid: I think you are being pretty reasonable. I, however, still would argue for the distributed approach when it comes to granting permissions like creating projects. We don't only spread the workload of user management: we also spread the responsibility. If you give someone the rights to create Toaster projects, we hope you know what you are doing. Of course, I just might be overly optimistic (I do tend to think the best of people) ;) Cheers Belén > >I hope my description was clear both regarding my concerns and the >proposed implementation. > >Cheers, >Mihail > >-----Original Message----- >From: [email protected] >[mailto:[email protected]] On Behalf Of Barros Pena, Belen >Sent: Friday, October 24, 2014 6:38 PM >To: [email protected] >Subject: [Toaster] [RFC] Toaster access control > >One of the new features we are supposed to deliver in Toaster 1.8 is >access control: i.e. the concept of users and permissions. This is the >Bugzilla entry for the design > >https://bugzilla.yoctoproject.org/show_bug.cgi?id=6233 > >I think there are basically 2 approaches we can take for access control: > >1. Top-down approach >2. Distributed approach > >1. The top-down approach > >This is the approach where there is an all powerful administrator that >creates users, grants them permissions and administers them. The all >powerful administrator is the access gatekeeper. If you want to use >Toaster you need to request access somehow. The all powerful >administrator will (or will not) grant you access, and will decide what >you can and cannot do in Toaster. > >This is a very common approach: Bugzilla works like this. Moderated >mailing lists work essentially like this. I believe Jenkins works like >this too. > >2. Distributed approach > >User management is a shared responsibility between all users who can >create Toaster projects. Users are invited to join a particular project >by the project creator. Project creators decide what the people they >invite can do within that project and within Toaster. > >This is the approach used by the Basecamp project management tool >(https://basecamp.com/). > >How both approaches compare? > >* In the top-down approach, the fundamental unit for user management is a >Toaster instance; in the distributed approach, the fundamental unit for >user management is a Toaster project. > >* The top-down approach requires a central place for user management that >can only be accessed by the all powerful administrator(s). This central >place is outside and above Toaster projects. In the distributed approach, >user management takes place within a Toaster project. > >* In the top-down approach, the user management task falls on the all >powerful administrator(s). In the distributed approach, user management >is shared between all project creators. > >* The top-down approach is request-based: I must solicit access to >Toaster to the all powerful administrator, who then decides which >projects I can access and what I can do in Toaster. The distributed >approach is >invitation-based: the project creator invites me to access her project. > >* In the top-down approach, there is normally one all powerful >administrator and then a whole bunch of Toaster users. In the distributed >approach, there are a whole bunch of project creators and a whole bunch >of project users. > >Which approach do I like best? The distributed one, of course. This is >why: > >1. Because so far we have designed Toaster to be project based. For >example, although there is a global layer list in the Toaster database >that spans all projects, layers are only exposed in the context of a >certain project. There are no Toaster pages outside of projects, apart >from the landing page. The distributed approach to access control >reflects this currently existing structure, which keeps things nice and >simple. > >2. Because it avoids the need for a global administration interface. >There are Toaster projects, and within a project you have a list of the >people who have access to that project. > >3. Because it shares the responsibility of user management: no single >person has to deal with this very annoying task. The responsibility is >shared between all project creators. > >4. Because it makes user management easier: no need to deal with a list >of a million users, and give each of them access to 50 projects. User >lists are broken down by project, which means shorter lists. Project >access granting happens organically, instead of in a single go. Inviting >existing users to a project is easy because we keep a global list of >users that spans all projects, even if we choose not to show it: typing a >name should provide you suggestions from existing users, and you can >select one of them or create a new one as needed. > >5. Because it avoids the need for sophisticated user management features, >such as Active Directory integration (don't laugh: >https://wiki.jenkins-ci.org/display/JENKINS/Active+Directory+plugin), >which we are in no position to deliver. > >But I am just the designer: what the hell do I know? So it would be good >to find out which approach you prefer and why. > >Thanks! > >Belén > >-- >_______________________________________________ >toaster mailing list >[email protected] >https://lists.yoctoproject.org/listinfo/toaster -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
