1. 04 Feb, 2015 1 commit
  2. 28 Jan, 2015 1 commit
  3. 27 Jan, 2015 1 commit
    • Leigh B Stoller's avatar
      Two co-mingled sets of changes: · 85cb063b
      Leigh B Stoller authored
      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.
      85cb063b
  4. 03 Jan, 2015 1 commit
  5. 18 Dec, 2014 1 commit
  6. 15 Dec, 2014 1 commit
  7. 03 Dec, 2014 1 commit
  8. 12 Nov, 2014 1 commit
    • Leigh B Stoller's avatar
      Lots of dataset changes. · 0adc340f
      Leigh B Stoller authored
      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.
      0adc340f
  9. 03 Nov, 2014 1 commit
  10. 28 Oct, 2014 1 commit
    • Leigh B Stoller's avatar
      Export methods that interface to backend createdataset and deletelease · 7bcc61cb
      Leigh B Stoller authored
      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.
      7bcc61cb
  11. 08 Oct, 2014 1 commit
  12. 07 Oct, 2014 1 commit
  13. 08 Sep, 2014 1 commit
  14. 26 Aug, 2014 1 commit
  15. 19 Aug, 2014 1 commit
  16. 22 Jul, 2014 1 commit
  17. 15 Jul, 2014 1 commit
  18. 14 Jul, 2014 1 commit
  19. 04 Jun, 2014 1 commit
  20. 02 Jun, 2014 1 commit
  21. 26 May, 2014 1 commit
  22. 18 May, 2014 2 commits
  23. 14 Apr, 2014 2 commits
    • Leigh B Stoller's avatar
      When calling DeleteSlice(), if a monitor process is running, then the · 09421138
      Leigh B Stoller authored
      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.
      09421138
    • Leigh B Stoller's avatar
      52292e36
  24. 10 Apr, 2014 1 commit
  25. 07 Apr, 2014 1 commit
  26. 31 Dec, 2013 1 commit
  27. 18 Dec, 2013 1 commit
  28. 07 Nov, 2013 1 commit
  29. 31 Oct, 2013 1 commit
  30. 18 Sep, 2013 1 commit
  31. 27 Aug, 2013 1 commit
  32. 19 Aug, 2013 1 commit
  33. 09 Aug, 2013 2 commits
    • Leigh B Stoller's avatar
      Remove code that extends slice lifetime, and fix underlying bug. · 60a34cdf
      Leigh B Stoller authored
      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.
      60a34cdf
    • Leigh B Stoller's avatar
      I added two new actions to PerformOperationalAction, which appear to · cfd1974a
      Leigh B Stoller authored
      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.
      cfd1974a
  34. 23 Jul, 2013 1 commit
    • Leigh B Stoller's avatar
      ABAC Speaksfor credential support. · 60274694
      Leigh B Stoller authored
      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 (:-).
      60274694
  35. 11 Jul, 2013 1 commit
    • Leigh B Stoller's avatar
      Implement speaksfor (non-abac) support. · 8d53b3fd
      Leigh B Stoller authored
      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.
      8d53b3fd
  36. 28 Jun, 2013 1 commit
  37. 28 May, 2013 1 commit
    • Leigh B Stoller's avatar
      Reorg the credential checking code, and add Geni chain checks. · dd5c6601
      Leigh B Stoller authored
      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!).
      dd5c6601