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
