-----Original Message-----
From: Barros Pena, Belen [mailto:[email protected]]
Sent: Thursday, May 29, 2014 2:54 AM
To: Bob Cochran; Wymore, Farrell; DAMIAN, ALEXANDRU; Reyna, David;
[email protected]
Subject: Re: [Toaster] Django user system and permissions
On 29/05/2014 03:59, "Bob Cochran" <[email protected]> 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
[email protected]
https://lists.yoctoproject.org/listinfo/toaster
