vsys provides a safe mechanism for non-privileged users to execute privileged commands.
This facility is especially important in virtualized environments, in which
users are not only restricted but also isolated. The mechanism is safe, as (i)
the commands available to a user (or virtual guest) are a predetermined set of
executable files, which can control the extent of access that the slice has to
the foreign context at a very fine grain and (ii) the authentication mechanism
of vsys relies on file-system isolation and does not require any explicit
negotiation when privileged services are invoked. vsys services are executable
files placed in a specific directory in the serving context. Slices that
subscribe to these services are populated with a pair of fifo pipes for each
available service. These pipes respectively become the input and output
channels to communicate with teh service.
For example, a script that would let a user fetch the list of slices from its
home site would look like this:
#!/usr/bin/perl
# Get the slice name ($ARGV[0])
$slice_name=$ARGV[0];
$slice_name=~m/(.*)_(.*)/;
$slice_site=$1;
open PWD, "/etc/passwd";
while () {
if (/$slice_site/) {
print $_;
}
}
close PWD;
Notes on using vsys
ACLs
Place a file named myscript.acl in the same directory as myscript to restrict myscript to the set of slices listed out in myscript.acl.
Script interface
First cmdline argument: slice name. STDIN - what the slice says STDOUT - mouthpiece for talking to the slice.
Dos and donts
Don't use "echo" to invoke a vsys script: echo invokes a new instance of bash, which sometimes dies before vsys can pull out all of the input. Use vsyssh wherever possible.
vsyssh
vsyssh lets you reuse tools with vsys scripts connected to stdin/stdout. It is executed as: vsyssh [cmd]. If cmd is omitted, then you get a vsyssh> prompt that you can type it to interact with the script at the backnd.