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.


--On March 30, 2009 5:26:26 PM -0400 Brian Bouterse <> 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.


Brian Bouterse
Secure Open Systems Initiative

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).


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, and perl modules.

There is another provisioning engine called - 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,, the Linux based installs
and environments uses the default 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 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
- 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

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 Peeler
OIT Advanced Computing
College of Engineering-NCSU

Reply via email to