Actually the mantra of VCL is broader than that - it's to broker remote
access to a resource. This resource being a node in a datacenter(that can
be reloaded), a standlone lab machine, or even a 'service'.
There are a few reasons why this should be optional.
One is CIPA related. With more users possibly using this in K-12 space and
since there is not a clear definition of how to make something CIPA
compliant. Folks might need to have this setting as an option to match
their CIPA solution.
The other is that not all the environments that VCL brokers access for -
needs to be or should be reloaded. One example - is the traditional lab
machines, these are idle resources that set in labs at night. Even though
some Univ are exploring the ideas of trimming back traditional labs, it's a
valuable resource that gets un-used in off hours when the computing labs
are closed. We don't want to reload this type of resource - but only broker
the access to it.
So it seems like the per-image basis is good enough to start with.
Aaron
--On March 30, 2009 5:26:26 PM -0400 Brian Bouterse <bmbou...@ncsu.edu>
wrote:
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
Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU
919.513.4571
http://vcl.ncsu.edu
