[WIP 0/4] Authorization utililty modules
The following patches provide modules to manage groups for the users Also pam modules are provided to check if a user is in one specific group Shu Ming (4): A module to manage the groups of the users A module to do pam account managment An example to demo how pam_members.so is used Configuration files for pam services src/kimchi/pam_members.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++ src/kimchi/pamauth_acc.py | 51 +++++++++++++++++++++++ src/kimchi/rolegroups.py | 36 ++++++++++++++++ src/kimchi/superadmin | 5 +++ src/kimchi/vmadmin | 5 +++ src/kimchi/vmuser | 5 +++ 6 files changed, 205 insertions(+) create mode 100644 src/kimchi/pam_members.c create mode 100644 src/kimchi/pamauth_acc.py create mode 100644 src/kimchi/rolegroups.py create mode 100644 src/kimchi/superadmin create mode 100644 src/kimchi/vmadmin create mode 100644 src/kimchi/vmuser -- 1.8.1.4
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 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() -- 1.8.1.4
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.
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()
-- Adam King <rak@linux.vnet.ibm.com> IBM CSI
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.
From your reply, I am not sure what is your implementation to have a group/role mapping. Can you explain it in detail?
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()
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?
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.
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()
-- Adam King <rak@linux.vnet.ibm.com> IBM CSI
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.
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? 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@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()
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
The steps to use this module 1) Built it into pam_members.so gcc -o pam_members.o -c pam_members.c -fPIC gcc -shared -Xlinker -x -o pam_members.so pam_members.o 2) Install pam_members.so into /user/lib64/security 3) Put your service configuration file into /etc/pam.d, see vmadmin, vmuser, superadmin for example 4) Call PAM.pam().acct_mgmt() to check if the user is in the group members see pamauth_acc.py for example Signed-off-by: Shu Ming <shuming@linux.vnet.ibm.com> --- src/kimchi/pam_members.c | 103 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 src/kimchi/pam_members.c diff --git a/src/kimchi/pam_members.c b/src/kimchi/pam_members.c new file mode 100644 index 0000000..ecd3797 --- /dev/null +++ b/src/kimchi/pam_members.c @@ -0,0 +1,103 @@ +/* + * A module to pam account managment, the steps to use this module + * 1) Built it into pam_members.so + * gcc -o pam_members.o -c pam_members.c -fPIC + * gcc -shared -Xlinker -x -o pam_members.so pam_members.o + * 2) Install pam_members.so into /user/lib64/security + * 3) Put your service configuration file into /etc/pam.d, see + * vmadmin, vmuser, superadmin for example + * 4) Call PAM.pam().acct_mgmt() to check if the user is in the group members + * see pamauth_acc.py for example + */ + +#include <stdio.h> +#include <stdlib.h> +#include <grp.h> +#include <string.h> +#include <syslog.h> +#include <libintl.h> +#include <pwd.h> +#include <security/pam_appl.h> + +int debug_mode = 0; + +#define debug_printf(fmt) if (debug_mode > 0) printf fmt + +int +pam_sm_acct_mgmt(pam_handle_t * pamh, int flags, int argc, const char **argv) +{ + char *user = NULL; + char *host = NULL; + char *service = NULL; + const char *allowed_grp = NULL; + char grp_buf[4096]; + struct group grp; + struct group *grps_ret; + struct pam_conv *conversation; + struct pam_message message; + struct pam_message *pmessage = &message; + struct pam_response *res = NULL; + int i; + int debug = 0; + + /* + * Set flags to display warnings if in debug mode. + */ + for (i = 0; i < argc; i++) { + if (strcasecmp(argv[i], "debug") == 0) + debug_mode = 1; + else if (strncmp(argv[i], "group=", 6) == 0) + allowed_grp = &argv[i][6]; + } + + /* + * Get user name,service name, and host name. + */ + (void) pam_get_user(pamh, &user, NULL); + (void) pam_get_item(pamh, PAM_SERVICE, (const void **) &service); + (void) pam_get_item(pamh, PAM_RHOST, (const void **) &host); + debug_printf(("user=%s, service=%s, host=%s\n", user, service, host)); + debug_printf(("allowed_grp=%s\n", allowed_grp)); + + /* + * Deny access if user is NULL. + */ + if (user == NULL) { + debug_printf(("user is NULL\n")); + return (PAM_USER_UNKNOWN); + } + + if (host == NULL) + host = "unknown"; + + /* + * Get the broken fileds from group database of allowed_grp + */ + if (getgrnam_r(allowed_grp, &grp, grp_buf, sizeof (grp_buf), &grps_ret) != 0) { + debug_printf(("%s: members_only: group %s not defined.\n", + service, allowed_grp)); + return (PAM_SYSTEM_ERR); + } + + /* + * Ignore this module if group contains no members. + */ + if (grp.gr_mem[0] == 0) { + debug_printf(("%s: members_only: group %s empty: " + "all users allowed.\n", service, grp.gr_name)); + return (PAM_IGNORE); + } + + /* + * Check to see if user is in group. If so, return SUCCESS. + */ + for (; grp.gr_mem[0]; grp.gr_mem++) { + debug_printf(("Check member %s: in group\n.", user)); + if (strcmp(grp.gr_mem[0], user) == 0) { + debug_printf(("%s: user %s is member of group %s. " + "Access allowed.\n", + service, user, grp.gr_name)); + return (PAM_SUCCESS); + } + } +} -- 1.8.1.4
See the comments in pam_members.c in detail Signed-off-by: Shu Ming <shuming@linux.vnet.ibm.com> --- src/kimchi/pamauth_acc.py | 51 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 src/kimchi/pamauth_acc.py diff --git a/src/kimchi/pamauth_acc.py b/src/kimchi/pamauth_acc.py new file mode 100644 index 0000000..da6a4c2 --- /dev/null +++ b/src/kimchi/pamauth_acc.py @@ -0,0 +1,51 @@ +# An example to demo how pam_members.so is used +# See the comments in pam_members.c +#!/usr/bin/env python + +import sys +import PAM + +if __name__ == '__main__': + + if len(sys.argv) == 2: + user = sys.argv[1] + else: + user = None + + auth = PAM.pam() + auth.start('vmadmin') + + if user != None: + auth.set_item(PAM.PAM_USER, user) + + auth.set_userdata("vmadmin data") + + try: + auth.acct_mgmt() + except PAM.error, (resp, code): + print 'Not vmadmin' + print 'Go away! (%s)' % resp + except: + print 'Internal error' + else: + print 'Good to go!' + + service = 'vmusr' + auth = PAM.pam() + auth.start('vmuser') + + if user != None: + auth.set_item(PAM.PAM_USER, user) + + auth.set_userdata("vmuser data") + + try: + auth.acct_mgmt() + except PAM.error, (resp, code): + print 'Not vmuser' + print 'Go away! (%s)' % resp + except: + print 'Internal error' + else: + print 'Good to go!' + -- 1.8.1.4
Three files are for three differnt groups/roles Signed-off-by: Shu Ming <shuming@linux.vnet.ibm.com> --- src/kimchi/superadmin | 5 +++++ src/kimchi/vmadmin | 5 +++++ src/kimchi/vmuser | 5 +++++ 3 files changed, 15 insertions(+) create mode 100644 src/kimchi/superadmin create mode 100644 src/kimchi/vmadmin create mode 100644 src/kimchi/vmuser diff --git a/src/kimchi/superadmin b/src/kimchi/superadmin new file mode 100644 index 0000000..eff335e --- /dev/null +++ b/src/kimchi/superadmin @@ -0,0 +1,5 @@ +auth required /lib64/security/pam_unix.so +account required pam_members.so group=root +~ +~ +~ diff --git a/src/kimchi/vmadmin b/src/kimchi/vmadmin new file mode 100644 index 0000000..d902d06 --- /dev/null +++ b/src/kimchi/vmadmin @@ -0,0 +1,5 @@ +auth required /lib64/security/pam_unix.so +account required pam_members.so group=vmadmin +~ +~ +~ diff --git a/src/kimchi/vmuser b/src/kimchi/vmuser new file mode 100644 index 0000000..1d26390 --- /dev/null +++ b/src/kimchi/vmuser @@ -0,0 +1,5 @@ +auth required /lib64/security/pam_unix.so +account required pam_members.so debug group=vmuser +~ +~ +~ -- 1.8.1.4
participants (3)
-
Adam King -
Leonardo Augusto Guimarães Garcia -
Shu Ming