VOStore interface

Guy Rixon gtr at ast.cam.ac.uk
Wed Aug 10 01:29:16 PDT 2005


On Tue, 9 Aug 2005, Reagan Moore wrote:

> Actually, VOSpace owns the data that is deposited into the store.
> VOSpace does not own the store.  Multiple VOSpace instances can
> deposit data into the same store under separate account identifiers.
> ...
> This is the model used by the SRB.  The local store recognizes
> multiple accounts, one for each VOSpace instance.  The VOSpace
> instances can be federated to enable sharing of data that is stored
> under different VOSpace account IDs.

In that case you presumably have authorization in your store such that a
VOSpace cannot access (or see) data-items owned by another VOSpace.

> The issue of authorization can then be handled separately by each
> VOSpace.  If VOSpace owns the data accessed through VOStore, VOSpace
> can manage the authorization, create access control lists for each
> file, and retrieve the data through a VOStore interface.  In this
> situation, VOStore provides a standard access mechanism for getting
> and putting files.

Yes, but until VOSpace exists (propably not until the end of 2006), we need a
way of using VOStores separately. Thus, we need both authentication and
minimal authorization in the stores. I think we all agree that the
mechanism needed to authenticate a space to a store will do to authenticate
any other agent to the store. My point is that the minimal authorization
policy - access by owner only - needed to allow spaces to share a store will
also do _in the interim_ to allow other agents to share direct access to a
store.

I agree that ACLs, user-settable permissions and data-sharing are better done
through the VOSpace layer. Therefore, we leave them out of VOStore and specify
the minimum that will allow stores to operate without spaces in 2005.

> The standard example is GridFTP.  This utility runs at root, uses
> grid certificates to authenticate access, and then switches the
> execution of GridFTP to the user's account.  The challenge is that
> each store accessed this way has to have accounts for each user, and
> they can only see the data they personally own.  If they want to
> share data, the system administrator has to establish an account for
> the new user, and the owner of the data must set up access permission
> to the new user.

Interesting, but not relevant, IMHO. We don't require users to have individual
local accounts on the computers running the VOStores. In fact, we strongly
require them _not_ to have such accounts; the management load on the sysadmins
would be too high. Therefore, the FTP model does not apply. Instead, we need
to track data-ownership in the service implementation, not in the account
running the code.

> If VOStore attempts to manage authorization, it will have to
> implement features similar to VOSpace.  VOStore would have to
> authenticate the user
> either check an access policy or ACL for each file
> run as root to switch to the account of the person that owns the file

We already agreed that authentication code is needed anyway; it can be the
same code whether or not we allow direct access to the store. Your email
implies that we also need to enforce data ownership when spaces share a store,
therefore we need minimal authorization code whether or not we allow direct
access to the store.

> If the authorization is managed by VOSpace, VOStore can run as
> middleware, and not require root access.

It can and it doesn't, regardless of whether VOSpace does the authorization.

> I prefer to put the
> authorization software either in the local store, or in the VOSpace
> layer to avoid the need for VOStore to run as root.

As argued above, some of the the permission checking has to happen inside the
store, in order to keep multiple clients (spaces) in line. It doesn't matter
whether this is done in the VOStore web-service or in the storage code that
the web-service calls. You can implement the check in the storage code hidden
behind the VOStore facade; another project can implement it in the web
service.

Remember, I'm not arguing for VOStore to have _permission-setting_ operations.
I want the access permissions on stores to be basic, implicit and fixed. I
expect all variable permissions, such as "write-protect this file" or "share
this file with user-group x" to be handled in VOSpace _exactly as you have
been advocating_. Yes, that means permission-checking in two places; no, that
need not lead to bad performance; no, it won't be expensive to code.

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523



More information about the vospace mailing list