[Kimchi-devel] [WIP 1/4] A module to manage the groups of the users

Mon Feb 17 17:59:35 UTC 2014

On 02/17/2014 05:24 AM, Shu Ming wrote:
> 2014/1/31 0:13, Adam King:
>> 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
> 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,
this user will be able to act on the Kimchi resources according to these
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
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.
>
>> One impediment to the proposed implementation will be the use of
>> read only LDAPs which will prevent Kimchi from creating groups.
>>> 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
>> 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.
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
> 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
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 at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel