<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">于 2014/1/20 21:58, Aline Manera 写道:<br>
</div>
<blockquote cite="mid:52DD2B97.9030608@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 01/15/2014 05:03 AM, Shu Ming
wrote:<br>
</div>
<blockquote cite="mid:52D632AF.7000209@linux.vnet.ibm.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<h1>Background</h1>
<br>
In Kimchi, now we have a basic authentication model based on
PAM. In this model, all the authenticated user get all of the
privileges to access the resources in Kimchi. However, it is too
simple to cause some security holes and classifying the user
with different roles is a way to address the holes. Roles with
very fine grained privileges need huge effort and time, so here
we are trying to split the effort with several steps. And we
will discuss the first step of the effort in the below which can
be achieved in a certain time bound and reserve the forward
compatibility for future extensions.<br>
<br>
<br>
<h1>First step of the effort</h1>
<br>
</blockquote>
<br>
I think managing kimchi users roles will be the next step of
authorization.<br>
<br>
The idea for now (Kimchi 1.2) is differ between root and non-root
users. What does that mean?<br>
Users in "sudo" linux group will have full access to kimchi. And
user not in this group will have limited access to kimchi.<br>
Users with "sudo" privilege will act as admin. <br>
<br>
<blockquote cite="mid:52D632AF.7000209@linux.vnet.ibm.com"
type="cite"> In this step, the goal is to authorize the user's
action on a resource by roles. The user action here is applied
by the REST API exposed by Kimchi. Every action on Kimchi
resources should be checked based on the user's role. In this
step, we will not try to have roles in a very fine granularity.
Naturally, three permanent roles will be created by default, the
system administrator role, the infrastructure role and the user
role.<br>
<br>
* The system administrator get the privileges to manage the
roles for the other users including assigning a role to a user,
removing the role from a user &etc. A default user "admink"
will be created by default with a system administrator role
assigned to it. And the role of the user "admink" can not be
modified. <br>
<br>
* The infrastructure role get the privileges to manage the
physical resources and virtual resources including network's
creation and deletion, create or delete storage storage pools or
storage volumes' creation and deletion, adding a user to the
user list of storage storage pool &etc. <br>
<br>
* The user role get the privileges to apply action on VMs
including VMs' starting and stopping, viewing the VM console by
VNC &etc.<br>
<br>
* Some of the change can be enhanced on the existing REST API
like "DELETE /storagepools/poo1/vo1". But we need create new
REST APIs for actions like adding a role for a user like " PUT
/users/user1 {role: "user role"}"<br>
<br>
* Database is needed to store the user information including
roles and resource user list<br>
</blockquote>
<br>
From my view, the roles will be user groups in linux system.<br>
So add an user to a role is add him to a group and we don't need
to keep the info internally.<br>
Internally we will only have the map: user group => allowed
URIs<br>
</blockquote>
Database is not necessary for this step. <br>
Assuming the users in user groups get the roles inferred from the
group may be not enough. Most of the user group in Linux hosts can
not mapped to a meaningful roles defined above. The only meaningful
logical group should be "root" group and "non-root" group which are
composed of other default groups in Linux host like "bin, "sys",
"adim" &etc. Further more, we should keep in mind that we will
use standard directory service like AD or LDAP to replace Linux
system users, so it is not a right direction to let Linux hosts
users to interfere with Kimchi authorization in a deeper way.<br>
<blockquote cite="mid:52DD2B97.9030608@linux.vnet.ibm.com"
type="cite"> <br>
<blockquote cite="mid:52D632AF.7000209@linux.vnet.ibm.com"
type="cite"> <br>
Beside the privileges inherited from the user's role, Kimchi
will check if a user get the permission to access a resource
based on a tuple. The tuple is composed from both the
privileges of the user and the user list of the resource. An
example is, if a user try ti delete a storage volume from the
stroage pool, Kimchi will check if it is assigned a
infrastructure role and if it is in the user list of the storage
pool.<br>
<br>
<h1>Next step of the effort</h1>
<br>
* The roles are defined in a very fine granularity containing
the privileges precisely matching what the system administrator
expects. <br>
<br>
* Existing roles can by customized by the system administrator
from a set of previleges. The set of privileges should be
pre-defined and hierarchy. <br>
<br>
* The system administrator can create new roles with customized
privileges <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>