On 1/29/2014 8:47 PM, Shu Ming wrote:
2014/1/30 4:10, Adam King:
On 1/29/2014 12:07 PM, Shu Ming wrote:
This module provide interfaces to create default groups for kimchi, vmuser and vmadmin. Also it provide interfaces to assign a user to one group as his supplementary group With the design we discussed on the list, we do not want or need to create kimchi unique groups. I think using supplementary group is a implementation detail, not necessary linked to the design. As I read the patch, I didn't view it as an implementation detail. Maybe I would see it differently if I had a better understanding of the meaning of "supplementary group". Can you elaborate? I think hard-map the users in sudo groups to the privileged users in Kimichi is a very rough assumption. I think nobody proposed to map user's rights into sudo groups only. We want to identify which users/groups have sudo rights (and, if they have rights to run any commands with sudo they have rights equivalent to the root user) and what other groups a user is part of. If you take a look at my patch merged this week, you'll see that it returns both the sudo rights and the list of groups a user is part of. The privilege of a user in Kimchi should be decided by Kimchi's super user which is a default one coming with Kimchi after the initial setup. For example, it is common for Kimchi to assign a user not in sudo group with some kind of admin
2014/1/31 0:13, Adam King: privileges. So I leverage the concept of 'supplementary group' to map the role to supplementary groups. Supplementary groups can help Kimchi to extend group/roles's granularity without side effect. I think this is the same thing as Adam is saying. If a user is part of a given group (no matter if you are calling it a supplementary group or just a group) identified by Kimchi as a group with certain privileges,
In my patch, a vmuser supplementary group is mapped to a normal VM user role in Kimchi, while vmadmin is mapped to a VM administrator role. Group names and roles can be defined and extended later. Here is the definition of 'supplementary group'from wikipedia: http://en.wikipedia.org/wiki/Group_identifier
“In Unix systems, every user must be a member of at least one group, which is identified by the numeric GID of the user's entry in /etc/passwd. This group is referred to as the primary group ID. A user may be listed as members of additional groups in the relevant groups entry in the /etc/group; the IDs of these groups are referred to as supplementary group IDs.”
In one word, supplementary group can be used in Kimchi to assign a Linux system user to different roles. Moreover, we can continue to use PAM way to do the authorization with Kimchi's own supplementary groups in my patch. Please reference [WIP 2/4] A module to do pam account management on how to integrate supplementary groups into the PAM module. I personally don't like the idea of having a PAM module. It seems to complicate something that is initially simple. We can create groups or add/remove users from groups using the common Linux command line tools. But, anyway, I think this kind of management is not something we might need at this moment. First we need to make it possible to differentiate
On 02/17/2014 05:24 AM, Shu Ming wrote: this user will be able to act on the Kimchi resources according to these privileges. the users and their groups. This is already merged. Next step, IMHO, is to implement more fine grained control to distinct who can access a VM or not. In a third moment we can think about an interface to manage groups and users.
From your reply, I am not sure what is your implementation to have a group/role mapping. Can you explain it in detail? My proposal is to store the group/role mapping in the <domain> document using the <metadata> tag. The authorization would be stored, and
One impediment to the proposed implementation will be the use of read only LDAPs which will prevent Kimchi from creating groups. transported with the VM definition. I suppose you mean VM XML definition here to store the group/role mapping. I am not sure VM XML definition is the right place to store this information which should be owned by Kimchi application.
The obvious issues will be: Which VM definition should be used from multiple VMs in Kimchi? Each VM has its own VM domain XML. So I don't think this is an issue. Is it necessary to store the mapping into all of the VMs' definition? Yep. I think that's the idea. If no map is stored, we can decied whether only root (or a user with sudo rights) is allowed to access the VM or if all users can access the VM. If yes, how can we sync the mapping between multiple VMs' definitions. I don't see your point here... We don't need to sync anything. If the root user wants, he can assign special rights for a user/group to access a VM. I think group/role mapping should stay in the host and VM migration should not change the group/role mapping in both the source and the destination host. If a VM is planned to be migrated from HOST A to HOST B, the user in HOST A should get VM administration role to launch the migration. After the VM is migrated to HOST B, the VM is a resource in HOST B and the user in HOST B can manage the VM with a specific role.
BTW: Is it arguable that if group/role mapping should be a shareable data between hosts after the federation comes to Kimchi. Migration and federation are not planned for this release. So I think we should not worry about them now. Let's keep the design simple and, in
I think it would be much better to not have any Kimchi specific information stored anywhere. I mean, no specific database or repository in Kimchi for information that can be easily stored in the system or in the VM domain XML. the future, when we would need to take migration and federation into account, it will be simple to change the design if necessary to include these features. Best regards, Leonardo Garcia
Signed-off-by: Shu Ming <shuming@linux.vnet.ibm.com> --- src/kimchi/rolegroups.py | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 src/kimchi/rolegroups.py
diff --git a/src/kimchi/rolegroups.py b/src/kimchi/rolegroups.py new file mode 100644 index 0000000..174c0f0 --- /dev/null +++ b/src/kimchi/rolegroups.py @@ -0,0 +1,36 @@ +import subprocess +import grp +from kimchi.utils import kimchi_log + +def new_group(gnam): + cmd = " ".join(('groupadd', gnam)) + + try: + subprocess.call(cmd, shell=True, + stdout=subprocess.PIPE, stderr=subprocess.PIPE) + except Exception, e: + kimchi_log.info('Exception running command %s: %s', cmd, e) + +def vmadmin_group_check(): + try: + grp.getgrnam("vmadmin") + except KeyError: + new_group("vmadmin"); + +def vmuser_group_check(): + try: + grp.getgrnam("vmuser") + except KeyError: + new_group("vmuser"); + +def user_add_group(usernam, grpnam): + cmd = " ".join(('usermod', '-a', '-G', grpnam, usernam) + try: + subprocess.call(cmd, shell=True, + stdout=subprocess.PIPE, stderr=subprocess.PIPE) + except Exception, e: + kimchi_log.info('Exception running command %s: %s', cmd, e) + +if __name__ == '__main__': + vmuser_group_check() + vmadmin_group_check()
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel