more on datastore

[Robert Olson]

including a first shot at access control definitions.


Bindings between DataStore and TransferEngine

A datastore can have multiple TransferEngines at its disposal to
provide for remote upload and download access to its files. Virtual
datastore pathnames are used as identifiers for files; that is, URLs
identifiying files will use the virtual pathname in the URL as the
path component of the URL. The host identification component of the
URL is bound to the TransferEngine instance.

In other words, when a DataStore wishes to advertise a URL for access
to a file or directory, it constructs that url based on the scheme and
authority provided by the TransferEngine (e.g. http://hostname:port)
and the virtual path of the file or directory in the DataStore.

When the TransferEngine receieves a request to GET or PUT a file at a
URL, it then is able to use the DataStore map this request to physical
file or directory and to perform authorization checks.

The binding between a DataStore and a TransferEngine is made at the
time these objects are created.

Access control for a node is inherited from its parent, unless it
defines its own policy. This allows a venue server to create a single
datastore and transfer server for all the venues it runs, assign a
directory to each venue, and allow the venue to manage the access
control on that venue.

---

Access Control

Each file and diretory has an access control list. There are different
options on each.

Files:
	read: Access allows the user to download the file.

	write: Access allows the user to overwrite or delete the file.

Directories:
	list: Access allows the user to list the contents of the
	directory.

	upload: Access allows the user to upload a new file into this
	direcctory. If the file already exist, he must have write
	access to the file.
	
	write: Access allows the user to delete or rename files, or to
	create new directories.

	read: Access allows user to read files in the directory.

	administer: Allows user to change access to the directory or
	contents of the directory

Note that these access rights are for external users coming through
the web services interface. The local user (the venue server process
itself, the client running a transient filestore) has complete control
through the local datastore API.

ACL use-cases:

(A) User uploads a file.

User must have upload perms on the directory. When the file has been
transferred, the user is given write permission on it. Read permission
on the file is set to "inherit", which means that read access is
inherited from the ACL of the containing directory.

(B) User creates a directory.

User must have write access to the containing directory. The new
directory is created with permissions copied from the containing
direcgtory.

(C) User uploads a directory.

The new directory is created as in (B), then each file uploaded as
in (A). If the user is uploading an entire directory hierarchy, the
empty directory hierarchy is created first, then the files uploaded.

(D) Permissions for a venue filestore

A per-venue file store will have directories with list, upload, read,
write access given to the users of the venue (via an indirection
mechanism in the datastore). administer privs go to the owner of the
venue.

(E) Permissions for a per-client transient filestore.

A transient filestore will have directories with list and read
permissions given to the current users of the venue (via an
indirection to the venue client. If the user desires, he could allow
transfers by opening upload or write permission to the datastore.