Django user system and permissions

Django user system and permissions

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

Hi,

Since we've been speaking of providing some sort of skeleton for users and
permissions, maybe this would be a good point to start:

https://docs.djangoproject.com/en/dev/topics/auth/#overview

Django's built in system is fairly versatile, and supports multiple backend
for user authentication. Also, there are countless modules supporting
extensions to this system on the internet.

Hope this helps,
Alex

-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 1403 bytes --]

Re: Django user system and permissions

[Wymore, Farrell]

[-- Attachment #1.1: Type: text/plain, Size: 1988 bytes --]

Hi Alex,

I’ve done a fairly thorough investigation of the Django authentication system and several of
the extensions.

The model I had in mind is similar to the linux filesystem authentication and permission model
of owner, group, and other with a similar set of permission bits. Django does part of this – the
authentication part – but not all. Django does have the notion of a ‘group’ but it is not the same
as the linux filesystem group. It’s more like a set of capabilities cast as a ‘group’.

The implementation I have locally, follows the linux filesystem model. The owner, group and
permission bits are applied to a build but could easily be applied to a project. The implementation
is simple and straight forward and seems to work. What is missing are the management screens
needed to create/delete groups, create/delete group members, and a way to set the permission
bits. When a project is created, the owner, default group and default permissions should be set.
This mechanism is not in place yet.

I’ve attached a (short) working paper. This is fairly high level but outlines the main ideas and
implementation plan. Everywhere the documents indicates a ‘build’, substitute ‘project’. Please
let me know what you think. Thanks.


-          fw

-


From: Damian, Alexandru [mailto:alexandru.damian@intel.com]
Sent: Wednesday, May 28, 2014 12:35 PM
To: Reyna, David; Wymore, Farrell; toaster@yoctoproject.org
Subject: Django user system and permissions

Hi,

Since we've been speaking of providing some sort of skeleton for users and permissions, maybe this would be a good point to start:

https://docs.djangoproject.com/en/dev/topics/auth/#overview

Django's built in system is fairly versatile, and supports multiple backend for user authentication. Also, there are countless modules supporting extensions to this system on the internet.

Hope this helps,
Alex

--
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #1.2: Type: text/html, Size: 12494 bytes --]

[-- Attachment #2: ToasterAuthentication_Belen-fw.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 27149 bytes --]

Re: Django user system and permissions

[Bob Cochran]

On 05/28/2014 04:35 PM, Wymore, Farrell wrote:
> I’ve attached a (short) working paper. This is fairly high level but
> outlines the main ideas and
>
> implementation plan. Everywhere the documents indicates a ‘build’,
> substitute ‘project’. Please
>
> let me know what you think. Thanks.
>


Hi Farrell,

I have a few questions about your document & Toaster in general:

Will the Toaster permissions correspond in any way to the actual build 
folders, or is this just permissions to access specific web pages and 
links (e.g., start build)?

A related question: Is the idea that a toaster user will never grab a 
shell?

If a user has basic permissions, can a user create a new image recipe, 
work directory, and bbappend files to create their own customized image? 
  If so, will the permission model also support the amount of storage 
available to the user?  You’ll probably want to prevent a user from 
creating an infinite number of new projects until the disks are exhausted.

Why is the Django admin application not supported in Toaster?  I just 
started using Toaster (but am a long time user of Django).  For local 
server use, I'll want to patch in the admin app.

Lastly, Upon initial review & use, Toaster seems awesome!

Thank you,

Bob Cochran

Re: Django user system and permissions

[Barros Pena, Belen]

On 29/05/2014 03:59, "Bob Cochran" <yocto@mindchasers.com> wrote:

>On 05/28/2014 04:35 PM, Wymore, Farrell wrote:
>> I¹ve attached a (short) working paper. This is fairly high level but
>> outlines the main ideas and
>>
>> implementation plan. Everywhere the documents indicates a Œbuild¹,
>> substitute Œproject¹. Please
>>
>> let me know what you think. Thanks.
>>
>
>
>Hi Farrell,

Hi Bob,

The answers to your questions are... well, that we don't have answers yet
:) Just to clarify: access control and permissions are not a key
deliverable for the 1.7 release. We'll make them happen if we can, subject
to the priority work being done. Some more details below.

>
>I have a few questions about your document & Toaster in general:
>
>Will the Toaster permissions correspond in any way to the actual build
>folders, or is this just permissions to access specific web pages and
>links (e.g., start build)?

Personally, I'd like to see permissions based on projects. Projects are
coming on the 1.7 release. A project will be a specific configuration you
can build against, making changes to it as needed of course (you might
want to change the value of a variable or add a layer or what not). If you
have a configuration that you know a few people will need to build
against, you give them "build access" to that project. If you want them to
be able to change the configuration, you give them "edit" (or write)
access. If you just want them to download the outcome of the builds (a
rootfs), you give them "download" (or read) access.

I think the Linux file system is very sophisticated, probably a bit too
much for a first implementation of access control in a web application.
Also, we might find we need different types of permissions other than read
and write. But everything is still very much in the air: we are still
discussing how to do this.

>
>A related question: Is the idea that a toaster user will never grab a
>shell?

That is an interesting question. I don't think the idea is to prevent
people from grabbing a shell: it's about providing alternatives to the
shell.

>
>If a user has basic permissions, can a user create a new image recipe,
>work directory, and bbappend files to create their own customized image?

See above: there might be different kinds of permissions, and permissions
could be allocated for a specific configuration (i.e. a project).

> 
>  If so, will the permission model also support the amount of storage
>available to the user?
>You¹ll probably want to prevent a user from
>creating an infinite number of new projects until the disks are exhausted.

This is a very good point: when we design the permissions system, we
should keep this in mind.


>
>Why is the Django admin application not supported in Toaster?

Alex will need to answer this one.

>I just 
>started using Toaster (but am a long time user of Django).  For local
>server use, I'll want to patch in the admin app.
>
>Lastly, Upon initial review & use, Toaster seems awesome!
>
>Thank you,
>
>Bob Cochran
>
>
>
>
>
>
>-- 
>_______________________________________________
>toaster mailing list
>toaster@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/toaster

Re: Django user system and permissions

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 4511 bytes --]

Hi all,

About the admin application - there are multiple reasons for why it wasn't
enabled.

- In the 1.6 release, Toaster had no user-writable data. An admin
application would not provide any feature we need.
- The data structures are complicated with multiple interdependent tables;
in order to provide admin access, we would've need to write a lot of code
(in admin model classes) to allow the admin interface make sense of the
data. This implies a lot of work, without any benefit in return.
- Enabling the admin system requires user accounts and enabling access
control. We don't have user objects, or an access control policy, so an
essential prerequisite of the admin application is missing.

I would love to hear your ideas about what kind of features would be
provided by having an admin application - maybe we can incorporate them in
plans for future versions.


Cheers,
Alex


On Thu, May 29, 2014 at 10:53 AM, Barros Pena, Belen <
belen.barros.pena@intel.com> wrote:

> On 29/05/2014 03:59, "Bob Cochran" <yocto@mindchasers.com> wrote:
>
> >On 05/28/2014 04:35 PM, Wymore, Farrell wrote:
> >> I¹ve attached a (short) working paper. This is fairly high level but
> >> outlines the main ideas and
> >>
> >> implementation plan. Everywhere the documents indicates a Œbuild¹,
> >> substitute Œproject¹. Please
> >>
> >> let me know what you think. Thanks.
> >>
> >
> >
> >Hi Farrell,
>
> Hi Bob,
>
> The answers to your questions are... well, that we don't have answers yet
> :) Just to clarify: access control and permissions are not a key
> deliverable for the 1.7 release. We'll make them happen if we can, subject
> to the priority work being done. Some more details below.
>
> >
> >I have a few questions about your document & Toaster in general:
> >
> >Will the Toaster permissions correspond in any way to the actual build
> >folders, or is this just permissions to access specific web pages and
> >links (e.g., start build)?
>
> Personally, I'd like to see permissions based on projects. Projects are
> coming on the 1.7 release. A project will be a specific configuration you
> can build against, making changes to it as needed of course (you might
> want to change the value of a variable or add a layer or what not). If you
> have a configuration that you know a few people will need to build
> against, you give them "build access" to that project. If you want them to
> be able to change the configuration, you give them "edit" (or write)
> access. If you just want them to download the outcome of the builds (a
> rootfs), you give them "download" (or read) access.
>
> I think the Linux file system is very sophisticated, probably a bit too
> much for a first implementation of access control in a web application.
> Also, we might find we need different types of permissions other than read
> and write. But everything is still very much in the air: we are still
> discussing how to do this.
>
> >
> >A related question: Is the idea that a toaster user will never grab a
> >shell?
>
> That is an interesting question. I don't think the idea is to prevent
> people from grabbing a shell: it's about providing alternatives to the
> shell.
>
> >
> >If a user has basic permissions, can a user create a new image recipe,
> >work directory, and bbappend files to create their own customized image?
>
> See above: there might be different kinds of permissions, and permissions
> could be allocated for a specific configuration (i.e. a project).
>
> >
> >  If so, will the permission model also support the amount of storage
> >available to the user?
> >You¹ll probably want to prevent a user from
> >creating an infinite number of new projects until the disks are exhausted.
>
> This is a very good point: when we design the permissions system, we
> should keep this in mind.
>
>
> >
> >Why is the Django admin application not supported in Toaster?
>
> Alex will need to answer this one.
>
> >I just
> >started using Toaster (but am a long time user of Django).  For local
> >server use, I'll want to patch in the admin app.
> >
> >Lastly, Upon initial review & use, Toaster seems awesome!
> >
> >Thank you,
> >
> >Bob Cochran
> >
> >
> >
> >
> >
> >
> >--
> >_______________________________________________
> >toaster mailing list
> >toaster@yoctoproject.org
> >https://lists.yoctoproject.org/listinfo/toaster
>
>


-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 6147 bytes --]

Re: Django user system and permissions

[Wymore, Farrell]

Hi Bob,

First, none of this is cast in stone. I did an initial investigation a few weeks ago
and created a prototype implementation. This feature is still very much under 
discussion.

To elaborate a little on Belen's comments:

-----Original Message-----
From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com] 
Sent: Thursday, May 29, 2014 2:54 AM
To: Bob Cochran; Wymore, Farrell; DAMIAN, ALEXANDRU; Reyna, David; toaster@yoctoproject.org
Subject: Re: [Toaster] Django user system and permissions

On 29/05/2014 03:59, "Bob Cochran" <yocto@mindchasers.com> wrote:

>>On 05/28/2014 04:35 PM, Wymore, Farrell wrote:
>>> I¹ve attached a (short) working paper. This is fairly high level but 
>>> outlines the main ideas and
>>>
>>> implementation plan. Everywhere the documents indicates a Œbuild¹, 
>>> substitute Œproject¹. Please
>>>
>>> let me know what you think. Thanks.
>>>
>>
>>
>>Hi Farrell,

>Hi Bob,

>The answers to your questions are... well, that we don't have answers yet
>:) Just to clarify: access control and permissions are not a key deliverable for the 1.7 release. We'll make them happen if we can, subject to the priority work being done. Some more details below.

This is a feature Wind River will  need (likely sooner than later). 
In the current prototype implementation, this feature can be turned off easily.

>>
>>I have a few questions about your document & Toaster in general:
>>
>>Will the Toaster permissions correspond in any way to the actual build 
>>folders, or is this just permissions to access specific web pages and 
>>links (e.g., start build)?

No. It is not the intention to mirror the host filesystem permissions. Rather the permissions are applied to database objects.
In the current prototype implementation, the permissions are applied to a build object. Permissions can be set such that one 
user can see and manipulate a build while others cannot. 

Sometime in the future permissions will likely be applied to projects, as Belen indicates below, rather than a single build.

>Personally, I'd like to see permissions based on projects. Projects are coming on the 1.7 release. A project will be a specific configuration you can build against, making changes to it as needed of >course (you might want to change the value of a variable or add a layer or what not). If you have a configuration that you know a few people will need to build against, you give them "build access" to >that project. If you want them to be able to change the configuration, you give them "edit" (or write) access. If you just want them to download the outcome of the builds (a rootfs), you give them >"download" (or read) access.

>I think the Linux file system is very sophisticated, probably a bit too much for a first implementation of access control in a web application.
>Also, we might find we need different types of permissions other than read and write. But everything is still very much in the air: we are still discussing how to do this.

The linux/unix filesystem is sophisticated but is also one of the simpler models. For Toaster, this model accomplishes 2 key things:
1) excludes users from builds they should not see/have access to, 2) allows a user to share a build with others.

>>
>>A related question: Is the idea that a toaster user will never grab a 
>>shell?

This would depend on a specific deployment. From a WindRiver point-of-view the answer is NO.

>That is an interesting question. I don't think the idea is to prevent people from grabbing a shell: it's about providing alternatives to the shell.

>>
>>If a user has basic permissions, can a user create a new image recipe, 
>>work directory, and bbappend files to create their own customized image?

>See above: there might be different kinds of permissions, and permissions could be allocated for a specific configuration (i.e. a project).
Belen's comment is spot on.

>> 
>>  If so, will the permission model also support the amount of storage 
>>available to the user?
>>You¹ll probably want to prevent a user from creating an infinite number 
>>of new projects until the disks are exhausted.

>This is a very good point: when we design the permissions system, we should keep this in mind.

I'm sure we'll need to impose limits of some kind (or charge real money). We haven't explored this
question.

>>
>>Why is the Django admin application not supported in Toaster?

I did investigate the Django admin. There are parts that can be used and is part of the prototype 
implementation. The Django admin is good for managing users and authenticating credentials.
Django also has capabilities which can be grouped together (called 'groups' in django) and assigned
to an object. This is not the same concept as the linux groups which represents one or more users.
Further, we want to assign permissions to a build/project and check this permission against some
credential. This is something Django does not do.

>Alex will need to answer this one.

>>I just
>>started using Toaster (but am a long time user of Django).  For local 
>>server use, I'll want to patch in the admin app.
>>
>>Lastly, Upon initial review & use, Toaster seems awesome!
>>
>>Thank you,
>>
>>Bob Cochran
>>
>>
>>
>>
>>
>>
>>
>>_______________________________________________
>>toaster mailing list
>>toaster@yoctoproject.org
>>https://lists.yoctoproject.org/listinfo/toaster

Re: Django user system and permissions

[Bob Cochran]

On 05/29/2014 01:46 PM, Wymore, Farrell wrote:
> Hi Bob,
>
> First, none of this is cast in stone. I did an initial investigation a few weeks ago
> and created a prototype implementation. This feature is still very much under
> discussion.
>
> To elaborate a little on Belen's comments:


Thank you Farrell, Belen, and Alex for the thorough replies.  I'll 
follow up later to some of the questions you posed after I become more 
familiar with Toaster on 1.6.

Regarding permissions, the Linux model, and a user getting access to a 
shell, it may be prudent to not implement a second set of permissions 
and just rely on (query) the OS each time the user makes a request of 
Toaster.  Each link could trigger a Javascript function that queries the 
Python server and the server in turn could query the OS for whether the 
user has permissions (from the OS) to execute the link / task.  Of 
course, the server would tailor the links shown on the Toaster web page 
based on the permissions granted by the OS (administrator).

This way the permissions would remain consistent if the user switched 
back & forth between Toaster and a shell.  My fear is that if you have 
two sets of permissions, it will create confusion and access control 
holes for this class of user (such as myself).

Thanks again,

Bob




>
> -----Original Message-----
> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
> Sent: Thursday, May 29, 2014 2:54 AM
> To: Bob Cochran; Wymore, Farrell; DAMIAN, ALEXANDRU; Reyna, David; toaster@yoctoproject.org
> Subject: Re: [Toaster] Django user system and permissions
>
> On 29/05/2014 03:59, "Bob Cochran" <yocto@mindchasers.com> wrote:
>
>>> On 05/28/2014 04:35 PM, Wymore, Farrell wrote:
>>>> I¹ve attached a (short) working paper. This is fairly high level but
>>>> outlines the main ideas and
>>>>
>>>> implementation plan. Everywhere the documents indicates a Œbuild¹,
>>>> substitute Œproject¹. Please
>>>>
>>>> let me know what you think. Thanks.
>>>>
>>>
>>>
>>> Hi Farrell,
>
>> Hi Bob,
>
>> The answers to your questions are... well, that we don't have answers yet
>> :) Just to clarify: access control and permissions are not a key deliverable for the 1.7 release. We'll make them happen if we can, subject to the priority work being done. Some more details below.
>
> This is a feature Wind River will  need (likely sooner than later).
> In the current prototype implementation, this feature can be turned off easily.
>
>>>
>>> I have a few questions about your document & Toaster in general:
>>>
>>> Will the Toaster permissions correspond in any way to the actual build
>>> folders, or is this just permissions to access specific web pages and
>>> links (e.g., start build)?
>
> No. It is not the intention to mirror the host filesystem permissions. Rather the permissions are applied to database objects.
> In the current prototype implementation, the permissions are applied to a build object. Permissions can be set such that one
> user can see and manipulate a build while others cannot.
>
> Sometime in the future permissions will likely be applied to projects, as Belen indicates below, rather than a single build.
>
>> Personally, I'd like to see permissions based on projects. Projects are coming on the 1.7 release. A project will be a specific configuration you can build against, making changes to it as needed of >course (you might want to change the value of a variable or add a layer or what not). If you have a configuration that you know a few people will need to build against, you give them "build access" to >that project. If you want them to be able to change the configuration, you give them "edit" (or write) access. If you just want them to download the outcome of the builds (a rootfs), you give them >"download" (or read) access.
>
>> I think the Linux file system is very sophisticated, probably a bit too much for a first implementation of access control in a web application.
>> Also, we might find we need different types of permissions other than read and write. But everything is still very much in the air: we are still discussing how to do this.
>
> The linux/unix filesystem is sophisticated but is also one of the simpler models. For Toaster, this model accomplishes 2 key things:
> 1) excludes users from builds they should not see/have access to, 2) allows a user to share a build with others.
>
>>>
>>> A related question: Is the idea that a toaster user will never grab a
>>> shell?
>
> This would depend on a specific deployment. From a WindRiver point-of-view the answer is NO.
>
>> That is an interesting question. I don't think the idea is to prevent people from grabbing a shell: it's about providing alternatives to the shell.
>
>>>
>>> If a user has basic permissions, can a user create a new image recipe,
>>> work directory, and bbappend files to create their own customized image?
>
>> See above: there might be different kinds of permissions, and permissions could be allocated for a specific configuration (i.e. a project).
> Belen's comment is spot on.
>
>>>
>>>   If so, will the permission model also support the amount of storage
>>> available to the user?
>>> You¹ll probably want to prevent a user from creating an infinite number
>>> of new projects until the disks are exhausted.
>
>> This is a very good point: when we design the permissions system, we should keep this in mind.
>
> I'm sure we'll need to impose limits of some kind (or charge real money). We haven't explored this
> question.
>
>>>
>>> Why is the Django admin application not supported in Toaster?
>
> I did investigate the Django admin. There are parts that can be used and is part of the prototype
> implementation. The Django admin is good for managing users and authenticating credentials.
> Django also has capabilities which can be grouped together (called 'groups' in django) and assigned
> to an object. This is not the same concept as the linux groups which represents one or more users.
> Further, we want to assign permissions to a build/project and check this permission against some
> credential. This is something Django does not do.
>
>> Alex will need to answer this one.
>
>>> I just
>>> started using Toaster (but am a long time user of Django).  For local
>>> server use, I'll want to patch in the admin app.
>>>
>>> Lastly, Upon initial review & use, Toaster seems awesome!
>>>
>>> Thank you,
>>>
>>> Bob Cochran
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> toaster mailing list
>>> toaster@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/toaster
>
>
>

Re: Django user system and permissions

[Wymore, Farrell]

All,

A few further comments about permissions:

Imagine Toaster as a host for a build farm.  Users log in through Toaster, configure and
launch builds, view and download their results. Now imagine what Toaster has to do to make
this happen:  User A logs in, configures and launches a build. Toaster has to create a directory
for that build and start the build process in that directory. Simultaneously, user B does the same
thing. Toaster has to be able to create N directories for N simultaneous users and be able to 
write into these directories and maintain them all separately. To complicate matters, user A
could start a second and a third build. Toaster will have to keep track of these builds on behalf of
each user. In this scenario Toaster is the owner of these directories, not the individual users.

In this scenario, users are not able to obtain a shell window into the build farm and do not have
and cannot obtain login credentials into the build server. Thus, permissions on the build directories 
are relevant only to Toaster. The user gets to see what Toaster allows the user to see based on the 
permissions the user has in Toaster.

This is only one use for Toaster and one use case scenario. Of course we can imagine others.

    - fw

-----Original Message-----
From: Bob Cochran [mailto:yocto@mindchasers.com] 
Sent: Friday, May 30, 2014 6:26 AM
To: Wymore, Farrell; BARROS PENA, BELEN; DAMIAN, ALEXANDRU; Reyna, David; toaster@yoctoproject.org
Subject: Re: [Toaster] Django user system and permissions

On 05/29/2014 01:46 PM, Wymore, Farrell wrote:
> Hi Bob,
>
> First, none of this is cast in stone. I did an initial investigation a 
> few weeks ago and created a prototype implementation. This feature is 
> still very much under discussion.
>
> To elaborate a little on Belen's comments:


Thank you Farrell, Belen, and Alex for the thorough replies.  I'll follow up later to some of the questions you posed after I become more familiar with Toaster on 1.6.

Regarding permissions, the Linux model, and a user getting access to a shell, it may be prudent to not implement a second set of permissions and just rely on (query) the OS each time the user makes a request of Toaster.  Each link could trigger a Javascript function that queries the Python server and the server in turn could query the OS for whether the user has permissions (from the OS) to execute the link / task.  Of course, the server would tailor the links shown on the Toaster web page based on the permissions granted by the OS (administrator).

This way the permissions would remain consistent if the user switched back & forth between Toaster and a shell.  My fear is that if you have two sets of permissions, it will create confusion and access control holes for this class of user (such as myself).

Thanks again,

Bob




>
> -----Original Message-----
> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
> Sent: Thursday, May 29, 2014 2:54 AM
> To: Bob Cochran; Wymore, Farrell; DAMIAN, ALEXANDRU; Reyna, David; 
> toaster@yoctoproject.org
> Subject: Re: [Toaster] Django user system and permissions
>
> On 29/05/2014 03:59, "Bob Cochran" <yocto@mindchasers.com> wrote:
>
>>> On 05/28/2014 04:35 PM, Wymore, Farrell wrote:
>>>> I¹ve attached a (short) working paper. This is fairly high level 
>>>> but outlines the main ideas and
>>>>
>>>> implementation plan. Everywhere the documents indicates a Œbuild¹, 
>>>> substitute Œproject¹. Please
>>>>
>>>> let me know what you think. Thanks.
>>>>
>>>
>>>
>>> Hi Farrell,
>
>> Hi Bob,
>
>> The answers to your questions are... well, that we don't have answers 
>> yet
>> :) Just to clarify: access control and permissions are not a key deliverable for the 1.7 release. We'll make them happen if we can, subject to the priority work being done. Some more details below.
>
> This is a feature Wind River will  need (likely sooner than later).
> In the current prototype implementation, this feature can be turned off easily.
>
>>>
>>> I have a few questions about your document & Toaster in general:
>>>
>>> Will the Toaster permissions correspond in any way to the actual 
>>> build folders, or is this just permissions to access specific web 
>>> pages and links (e.g., start build)?
>
> No. It is not the intention to mirror the host filesystem permissions. Rather the permissions are applied to database objects.
> In the current prototype implementation, the permissions are applied 
> to a build object. Permissions can be set such that one user can see and manipulate a build while others cannot.
>
> Sometime in the future permissions will likely be applied to projects, as Belen indicates below, rather than a single build.
>
>> Personally, I'd like to see permissions based on projects. Projects are coming on the 1.7 release. A project will be a specific configuration you can build against, making changes to it as needed of >course (you might want to change the value of a variable or add a layer or what not). If you have a configuration that you know a few people will need to build against, you give them "build access" to >that project. If you want them to be able to change the configuration, you give them "edit" (or write) access. If you just want them to download the outcome of the builds (a rootfs), you give them >"download" (or read) access.
>
>> I think the Linux file system is very sophisticated, probably a bit too much for a first implementation of access control in a web application.
>> Also, we might find we need different types of permissions other than read and write. But everything is still very much in the air: we are still discussing how to do this.
>
> The linux/unix filesystem is sophisticated but is also one of the simpler models. For Toaster, this model accomplishes 2 key things:
> 1) excludes users from builds they should not see/have access to, 2) allows a user to share a build with others.
>
>>>
>>> A related question: Is the idea that a toaster user will never grab 
>>> a shell?
>
> This would depend on a specific deployment. From a WindRiver point-of-view the answer is NO.
>
>> That is an interesting question. I don't think the idea is to prevent people from grabbing a shell: it's about providing alternatives to the shell.
>
>>>
>>> If a user has basic permissions, can a user create a new image 
>>> recipe, work directory, and bbappend files to create their own customized image?
>
>> See above: there might be different kinds of permissions, and permissions could be allocated for a specific configuration (i.e. a project).
> Belen's comment is spot on.
>
>>>
>>>   If so, will the permission model also support the amount of 
>>> storage available to the user?
>>> You¹ll probably want to prevent a user from creating an infinite 
>>> number of new projects until the disks are exhausted.
>
>> This is a very good point: when we design the permissions system, we should keep this in mind.
>
> I'm sure we'll need to impose limits of some kind (or charge real 
> money). We haven't explored this question.
>
>>>
>>> Why is the Django admin application not supported in Toaster?
>
> I did investigate the Django admin. There are parts that can be used 
> and is part of the prototype implementation. The Django admin is good for managing users and authenticating credentials.
> Django also has capabilities which can be grouped together (called 
> 'groups' in django) and assigned to an object. This is not the same concept as the linux groups which represents one or more users.
> Further, we want to assign permissions to a build/project and check 
> this permission against some credential. This is something Django does not do.
>
>> Alex will need to answer this one.
>
>>> I just
>>> started using Toaster (but am a long time user of Django).  For 
>>> local server use, I'll want to patch in the admin app.
>>>
>>> Lastly, Upon initial review & use, Toaster seems awesome!
>>>
>>> Thank you,
>>>
>>> Bob Cochran
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> toaster mailing list
>>> toaster@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/toaster
>
>
>