Browse Prior Art Database

System and Method for centralizing role management by virtualization of roles on Workload Partitions

IP.com Disclosure Number: IPCOM000201557D
Publication Date: 2010-Nov-15
Document File: 4 page(s) / 115K

Publishing Venue

The IP.com Prior Art Database

Abstract

This paper discloses a method by which the management of roles within WPAR Workload Partitions on UNIX platforms) is simplified. This is achieved by a new concept which is proposed by this paper termed ‘virtual roles’.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 01 of 4

System and Method for centralizing role management by virtualization of roles on Workload Partitions

The chief advantages of the proposed method are:-

1) Centralizing the role management function is done by enhancing a functionality already existing in the system without the requirement of any extra set of software such as LDAP. This also eliminates the administration overhead associated with external software such as LDAP.

2) This method represents a subtle form of virtualization. It enables sharing of roles across the system, but at the same time, keeps the sharing transparent to the WPARs.

A comparison between the existing technologies and the proposed.

1)

NAMESPACES

a) In namespaces, the namespaces are shared between the containers in which case root of either the container or the global system can change the contents of the namespace.

In our proposal, we restrict the editing of the roles only to the global system where-by we can allow a totally different person to be "root" for that particular system WPAR.

So, say in a scenario such as running DB2 inside a WPAR, we can make the db2 admin as the "root" for that WPAR as it is dedicated to running that DB2. If we had the concept of namespaces applied over here, then the "db2 admin" who is the "god of lesser things", in this case root for that WPAR, would be able to edit roles and make the changes reflect across the system WPAR as well as all other WPARs that share the same namespace.

b) Also, in namespaces an identifier with same name can exist in multiple namespaces. In such an arrangement an identifier occurring in one namespace may or may not have the same meaning as the one defined in the other namespaces.

So in a scenario like the following

namespace A : R1 R2 R3 R10 roles

namespace B : R10 R20 R30 R40 roles

And when a new namespace which contains R1 R2 R3 from namespace A and R10 R20 R30 from namespace B needs to be created, we cannot combine the above namespaces (A and B ) as R10 appears in both namespaces and there is no guarantee that they are the same. So we will have to create namespace C separately.

Thus, in scenarios similar to the above, for the worst-case scenario, we will have to create as many namespaces on each of the WPARs. So the complexity is (n).

1


Page 02 of 4

In our disclosure since the conflicts are intrinsically taken care of as shown below, our complexity is (1).

2) Issues with an automated script

a) The admin will have to consciously execute the script to reflect the changes made to the roles on the global system so that they are reflected inside the WPAR.

b) Having a feature at the kernel level is much faster than having something as a utility tool.

c) Hijacking a script or a process can happen in case of this feature being a utility tool and is ruled out when its a feature at the kernel level.

d) The scripting approach will be more of a superficial approach as its based in the user space. It can be a script which will import/export role related fil...