Opened 10 years ago

Closed 10 years ago

#85 closed (fixed)

Slice credentials are not checked when executing listresources on a sliver

Reported by: Owned by:
Priority: major Milestone:
Component: AM Version: SPIRAL4
Keywords: Cc:


Problem scenario:

A user creates two slices with one sliver in each, then downloads the slice credentials for the first slice, and then executes a ListResources? on the second slice. It seems that the slice credentials are not checked, because the credentials for the second slice can be successfully used to execute a listresources for the first slice.

Following is a capture:

$ -a exobbn getslicecred lnslice1 -o
INFO:omni:Loading config file omni_config
INFO:omni:Using control framework pgeni
INFO:omni:Slice expires on 2012-07-27 16:52:04 UTC
INFO:omni:Retrieved slice cred for slice
INFO:omni:Wrote slice lnslice1 credential to file 'lnslice1-cred.xml'
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed getslicecred:

  Options as run:
		aggregate: exobbn
		framework: pgeni
		native: True
		output: True

  Args: getslicecred lnslice1

  Result Summary: Saved slice lnslice1 cred to file lnslice1-cred.xml 
INFO:omni: ============================================================

$ -a exobbn listresources lnslice2 --slicecredfile ./lnslice1-cred.xml -o 
INFO:omni:Loading config file omni_config
INFO:omni:Using control framework pgeni
INFO:omni:Saving output to a file.
INFO:omni:Getting slice credential from file ./lnslice1-cred.xml
INFO:omni:Gathering resources reserved for slice lnslice2.
INFO:omni:Substituting AM nickname exobbn with URL, URN unspecified_AM_URN
INFO:omni:Listed resources on 1 out of 1 possible aggregates.
INFO:omni:Writing to 'lnslice2-rspec-bbn-hn-exogeni-net-11443-orca.xml'
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed listresources:

  Options as run:
		aggregate: exobbn
		framework: pgeni
		native: True
		output: True
		slicecredfile: ./lnslice1-cred.xml

  Args: listresources lnslice2

  Result Summary: Retrieved resources for slice lnslice2 from 1 aggregates.
Wrote rspecs from 1 aggregates to 1 files
Saved listresources RSpec at 'unspecified_AM_URN' to file lnslice2-rspec-bbn-hn-exogeni-net-11443-orca.xml; . 
INFO:omni: ============================================================

Also tried the other AM API functions:"sliverstatus", "deletesliver", "createsliver", and "renewsliver"; each of these function does check the credentials and fail as expected:

Credendial Exception: No credential was found with appropriate privileges.

Change History (6)

comment:1 Changed 10 years ago by

Also tested this scenario with two different user accounts ( and As checked access to sliver AM API functions with other user credentials. The following commands were tried and failed as expected:

lnevers1@sendaria$ -a exobbn listresources lnevers-slice --slicecredfile ./lnevers-slice-cred.xml 

lnevers1@sendaria$ -a exobbn sliverstatus lnevers-slice --slicecredfile ./lnevers-slice-cred.xml 

lnevers1@sendaria$  -a exobbn renewsliver lnevers-slice --slicecredfile ./lnevers-slice-cred.xml 2012-07-28

lnevers1@sendaria$ -a exobbn shutdown lnevers-slice --slicecredfile ./lnevers-slice-cred.xml 

lnevers1@sendaria$ -a exobbn deletesliver lnevers-slice --slicecredfile ./lnevers-slice-cred.xml 

lnevers1@sendaria$ -a exobbn createsliver lnevers-slice --slicecredfile ./lnevers-slice-cred.xml ./exo-2vm-1lan.rspec 

comment:2 Changed 10 years ago by

That's a feature, not a bug. We allow users to list. You should not however be able to do anything else (like delete the slice).

comment:3 Changed 10 years ago by

Ilia: Sorry for the delay - we've been looking hard at the API and testing your implementation of it. You've seen the added bug #86 and #87 as a result. We're still doing tests.

We believe this is in fact a bug. Users must supply a valid slice credential to operate on a slice, even listresources. Arguably the documentation is not clear (and we've tried to improve it for AM API v3), but this violates the intent of the API.

The API requires that operations on a slice include a valid credential whose target grants permissions on that slice. We believe you are not enforcing this consistently. AM-local knowledge of who created the slivers is not supposed to trump the provided credentials.

So listresources must take a valid slice credential for this slice and this user - not a different slice credential or a user credential.

For the relevant sections of the API, see: "At least one credential must be a valid slice credential for the slice specified in slice_urn if that is an argument .... Credentials must be valid ( ... and grant privileges to the client identified by the SSL client certificate)."

(See also

There are 5 elements to consider:

  1. User who created the slivers at this AM
  2. Client user (identified by the SSL client certificate)
  3. Credential owner (Owner GID: user in the slice credential)
  4. Credential target (Target GID: slice in a slice credential, user in a user credential)
  5. Slice URN (slice you are trying to operate on).

The quote from the API spec above tells me that:

  1. 4 must be = 5. Credential target must identify the same slice as the slice URN. If you are operating on a slice, then you must provide a credential granting permissions on that slice - not on the user, and not on another slice. We believe that you are not enforcing this consistently. Hence this ticket (and others).
  2. 2 must be = 3. SSL Client certificate must match the Credential Owner GID. The provided credential must grant rights to the caller. Not to another user over the same slice, but to you. We believe you are correctly enforcing this.

comment:4 Changed 10 years ago by

Owner: changed from somebody to
Status: newassigned


comment:5 Changed 10 years ago by

Problen resolution verified, the listresources now also check the slice credentials. Problem is addressed, closing ticket.

comment:6 Changed 10 years ago by

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.