Since we're brainstorming, why not give all users sudo access all the time and not have a distinction between root and/or admin level access? The mantra of VCL (I think) is to provision a resource and then blow it away, so why not let them have freedom in this temporary environment all the time?

If there is a distinction between root/admin, doing it on a per-image basis alone, makes sense to me.

Best,
Brian


Brian Bouterse
Secure Open Systems Initiative
919.698.8796




On Mar 30, 2009, at 4:25 PM, Aaron Peeler wrote:


The latest commit by Brian highlighted that a feature change for root/admin access might be needed for a future release(maybe for release 2.2).

Background:

Under certain provisioning engines or OS modules 'root/admin' level access is granted because the node can be reloaded. Also enabling root/admin access provides a lot of user benefits. Under non-imaging reservations it gives users a level of control they can't get in traditional lab machines or remote access machines, it provides a sense of ownership, etc. The modules that do provide root/admin access are xcat.pm,vmware.pm and esx.pm perl modules.

There is another provisioning engine called Lab.pm - it is for *nix machines that are locked down. Basically it opens and closes access for the requesting account. There is no reloading of the node involved and no root privileges. It is for standalone machines somewhere on the network, where the sysadmin does not want(or cannot allow) the users to have root level access.


Within the modules xcat.pm,vmware.pm,esx.pm the Linux based installs and environments uses the default Linux.pm OS module which uses the group 'ncsu' when the user account gets created on the node. This group is used as a method to quickly provide full sudo access for the requesting user. The user group ncsu is defined in /etc/sudoers when the image is setup(undocumented).

Suggested changes/enhancement:

Obviously the group name ncsu should be changed to something more intuitive, 'rootusers' or 'powerusers' or whatever. The default grant_access routine in Linux.pm would create the group and populate the sudoers file - if the group didn't already exist.

So the question is.
Are there any thoughts on doing this on a either or all of the following:
- per image/environment basis
- a per user basis
- a user group attribute
- or at a privilege node

Based on the provisioning or OS module the default could be to provide root/admin access. Then start to examine the attributes for the user, the user group, then the image. We'd have to defined which one 'user|usergroup|image|privnode' overrules the others. For example the image profile would have to allow root access first, then if the user is granted root access either at a privilege node or .

If triggered the grant_access routine would be responsible for providing(or not providing) root or admin level access.

A problem I can see immediately with this if we did all the options, is how to distinguish which one is final say. If the imageprofile is ok to allow root access - but if the user is granted image checkout at two or more nodes for the same image, one privilege node allowing root and the other privilege node not allowing root, which gets chosen?

So it might make sense to grant root only on per image basis? Kind of like what we're doing now, just the modification would be for the grant_access routines to create the needed rootuser group.

I've not given this a great deal of thought and I'm probably missing something, or it's just all unclear to folks. At this point this is just brain storming on how to make the root/administrative permission more dynamic.

BTW - created jira issue VCL-125 on this.

Aaron


Reply via email to