GitLab

people who want it. Set the creator_urn of image properly; we were not
handling it in the presence of a speaksfor credential. Minor dataset tweaks.

are a pain since access is not by credential or user.

1) Implement the latest dataset read/write access settings from frontend to
   backend. Also updates for simultaneous read-only usage.

2) New configure options: PROTOGENI_LOCALUSER and PROTOGENI_GENIWEBLOGIN.

   The first changes the way that projects and users are treated at the
   CM. When set, we create real accounts (marked as nonlocal) for users and
   also create real projects (also marked as nonlocal). Users are added to
   those projects according to their credentials. The underlying experiment
   is thus owned by the user and in the project, although all the work is
   still done by the geniuser pseudo user. The advantage of this approach
   is that we can use standard emulab access checks to control access to
   objects like datasets. Maybe images too at some point.

   NOTE: Users are not removed from projects once they are added; we are
   going to need to deal with this, perhaps by adding an expiration stamp
   to the groups_membership tables, and using the credential expiration to
   mark it.

   The second new configure option turns on the web login via the geni
   trusted signer. So, if I create a sliver on a backend cluster when both
   options are set, I can use the trusted signer to log into my newly
   created account on the cluster, and see it (via the emulab classic web
   interface).

   All this is in flux, might end up being a bogus approach in the end.

up the embedding so that its less confusing.

all users. Cloudlab added to the list, but not exposed except to
admins and studly users.

Project leases are now per-group, so we build a sub authority certificate
for a remote dataset so that on the remote side, it is created inside the
group named by the project on the local side.

Many bug fixes.

much quicker.

scripts. Also add a describe method.

In order to create a dataset, the caller must either be a local user, or
have an extra credential that grants the "blockstores" priv.

Like slivers, datasets are currently created in the holding project and
group corresponding the SA and subauthority.

Eventually need to add sharing control (say, to make a dataset globally
read only), but that does not exist in the backend yet.

geni_client_id in the AM SliverStatus and Describe methods. Requested by
Aaron.

Also a fix to Credential2SliceAggregate.

updated cert for a slice and we need to replace it in our
database. We were already doing this in the CM code, but we
missed a spot in the CMV2 code.

node state in sliver status. Use a web task to track create image
and return status from ImageInfo.

slice is busy.  This might mean that the user will not be able to
delete the slice for a long time, but we are having problems with
users canceling slices before they finish setting up, and the XEN
client side is not handling this very well. Note that the cleanupslice
script calls GeniCM::CleanupDeadSlice() directly, which *does* kill
the monitor, so admin cleanup is not affected.

Regarding the xen client side, signals can be blocked for a really
long time while a container is setting up, and so trying to kill it
fails, and bad things ripple out. Fixing that is going to take some
time to get right, so just avoid the problem for now.

Also add a simple test script.

that will allow the caller to access a console line (for a brief
moment in time).

shared. This was requested at GEC 18.

When unsharing (or terminating) a slice that contains shared vlans,
the sharing is revoked from all slices using that vlan.

For the latter, we now look to see if we already have an experiment
with the provide slice ID, and if we do and the URN indicates a sub
project, generate a new unique experiment name for the backend emulab
experiment.

We currrently have a few cases where a slice record exists, but
no sliver, and so Renew was failing. Since we store all of the
expiration in the slice record, we do not actually need to have
an aggregate, so remove the check.

work fine when the nodes are behaving themselves.

1) geni_update_users: Takes a slice credential and a keys argument. Can
  only be invoked when the sliver is in the started/geni_ready state.
  Moves the slice to the geni_updating_users state until all of the
  nodes have completed the update, at which time the sliver moves back
  to started/geni_ready.

2) geni_updating_users_cancel: We can assume that some nodes will be whacky
  and will not perform the update when told to. This cancels the
  update and moves the sliver back to started/geni_ready.

A couple of notes:

* The current emulab node update time is about three minutes; the
  sliver is in this new state for that time and cannot be restarted or
  stopped. It can of course be deleted.

* Should we allow restart while in the updating phase? We could, but
  then I need more bookkeeping.

* Some nodes might not be running the watch dog, or might not even be
  an emulab image, so the operation will never end, not until
  canceled. I could add a timeout, but that will require a monitor or
  adding DB state to store the start time.

The CM can now receive either an ABAC or a non-ABAC speaksfor
credential in the list of credentials. Thanks to Gary for getting
libabac built on boss so that I could use it! The AM probably needs a
little bit more work since it has a few V3 places where it does not
invoke CMV2 directly, but that should be easy to fix; all of the AMV2
functions will work tough.

Caveat; I don't bother to look at the speaksfor option; if we get a
speaksfor credential, I figure it was cause the user wants to use it!

I added a hacky script called genspeaksfor to create a proper speaks
for credential that allows me to speak for another user. For example:

	genspeaksfor -a urn:publicid:IDN+emulab.net+user+leebee \
	         urn:publicid:IDN+emulab.net+user+stoller

which generates an ABAC speaks for credential that allows me to spead
for leebee. To use the PG test scripts with this credential:

	createsliver.py* -S speaksfor.cred -s slice.cred

Where slice.cred is a plain slice credential issued to leebee and then
given to me via an out of band mechanism (:-).

CM V2 (and thus the AM) now accept a type=speaksfor credential along
with regular credentials. When supplied, the speaksfor caller must be
equal to the owner of the speaksfor credential and the target must be
equal to the owner of the regular credential(s). All operations take
place in the context of the spokenfor user.

Added speaksfor slots to geni_slices,geni_aggregates and geni_tickets.
Also to the history table. But these are just the most recent data.
Each transaction is logged as normal, and the metadata now includes
the speaksfor data and the log always includes all of the credentials.

For testing, there is a new script in the scripts directory to
generate a speaksfor credential. Not installed since it is really
a hack. But to create one:

  perl genspeaksfor urn:publicid:IDN+emulab.net+user+leebee \
	urn:publicid:IDN+emulab.net+user+stoller

which generates a speaksfor credential that says stoller is speaking
for leebee.

Given a slice credential issued to leebee, the test scripts can be
invoked as follows (by stoller):

  createsliver.py -S speaksfor.cred -s slice.cred -c leebee.cred

A copy of leebee's self credential is needed simply cause of the test
script's desire to talk to the SA (which does not support speaksfor).
Not otherwise needed.

Oh, not tested on the AM interface yet.

It is possible for the CM daemon to grab the lock for a moment,
so lets not fail. Rare case.

From: Leigh Stoller <lbstoller@gmail.com>
Date: Wed, 22 May 2013 13:49:33 -0700
Cc: instageni-design@geni.net

So far we have been pretty loose about checking to make sure the
certificate chains obey the Geni rules. These rules include checking to
make sure that only approved entities can sign particular kinds of
credentials. For example; only something known to be a Slice Authority
should be allowed to create a slice and return a slice credential.

The other check we have been lax about, is verifying that the URN namespace
is consistent along the chain from CA to the target. For example, a chain
that starts in Utah:

	URI:urn:publicid:IDN+emulab.net+authority+root

should not be able to sign anything outside its namespace. That is, Utah
should not be able to sign a user or slice credential like:

	urn:publicid:IDN+panther+user+shufeng

This is made more complicated when we introduce subsa certs along the way,
where Utah signs its SA cert and that signs a project slice. In this case
the chain would look something like:

	URI:urn:publicid:IDN+emulab.net+authority+root
	URI:urn:publicid:IDN+emulab.net+authority+sa
        URI:urn:publicid:IDN+emulab.net:testbed+authority+sa
        URI:urn:publicid:IDN+emulab.net:testbed+slice+myslice

There are also scoping rules; A subsa like:

        URI:urn:publicid:IDN+emulab.net:testbed+authority+sa

should not be able to sign:

        URI:urn:publicid:IDN+emulab.net:someotherproject+slice+myslice

The entire cert chain is require to verify this. The CA roots are in the
bundle, and the intermediate certs should be enclosed in the signature
section of the XML document.

We have to make the same check against the user certificate after apache
verifies the chain. For apache (or any SSL server) you have to load the
chain, and as I mentioned in earlier email, this is easy with perl and
python based clients.

With all that said, we do not plan to start rigorous enforcement of the
first check above, and for the second class of checks, we just want to
enforce a simple prefix check until we get our subsa house in order (since
we don't even conform properly yet!).