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

[Shu Ming]

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. 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. 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. 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.

>
> 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. The
obvious issues will be: Which VM definition should be used from multiple
VMs in Kimchi? Is it necessary to store the mapping into all of the VMs'
definition? If yes, how can we sync the mapping between multiple VMs'
definitions. 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.
>
>>>> 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()