Account ACLs (X-Account-Acl-Read-Only etc.)

Accounts now have three headers that represent ACLs, so that auth systems
can easily represent general account access (as opposed to container-level
access).  These headers are X-Account-Acl-Read-Only, X-Account-Acl-Read-Write,
and X-Account-Acl-Admin.

Read-only access is intended to indicate to the auth system that this
list of identities can read everything (except privileged headers) in
the account.  Specifically, a user with read-only account access can get
a list of containers in the account, list the contents of any container,
retrieve any object, and see the (non-privileged) headers of the
account, any container, or any object.

Read-write access is intended to indicate to the auth system that this
list of identities can read or write any of the targets described above
under read-only access.  A user with read-write account access can create
new containers, set any unprivileged account headers, set any unprivileged
container headers, overwrite objects, delete containers, etc.

Admin access is intended to indicate to the auth system that this list of
identities has "swift_owner" privileges.  A user with admin account access
can do anything the account owner can, including setting privileged headers
-- and thus granting read-only, read-write, or admin access to other users.

The auth system is responsible for making decisions based on these headers,
if it chooses to support their use.

Privileged headers are intended to include X-Container-Read and -Write,
X-Account-Meta-Temp-Url-Key and -Key-2, and of course these account ACL
headers themselves.  Again, it is the auth system's responsibility to
enforce the correct access if the auth system chooses to support account
ACLs.  (If the auth system doesn't support account ACLs, then currently
only the account owner will be able to read or write any account
headers, and other users will only have the existing ways to access
containers and objects.  If future auth systems implement other access
schemes at the account level, they'll all have to play nice together in
order to avoid security issues.)

Change-Id: I2260083f046e911bc5fdaf7728b77746b42a12bd
Account ACLs (X-Account-Acl-Read-Only etc.)

Accounts now have three headers that represent ACLs, so that auth systems
can easily represent general account access (as opposed to container-level
access).  These headers are X-Account-Acl-Read-Only, X-Account-Acl-Read-Write,
and X-Account-Acl-Admin.

Read-only access is intended to indicate to the auth system that this
list of identities can read everything (except privileged headers) in
the account.  Specifically, a user with read-only account access can get
a list of containers in the account, list the contents of any container,
retrieve any object, and see the (non-privileged) headers of the
account, any container, or any object.

Read-write access is intended to indicate to the auth system that this
list of identities can read or write any of the targets described above
under read-only access.  A user with read-write account access can create
new containers, set any unprivileged account headers, set any unprivileged
container headers, overwrite objects, delete containers, etc.

Admin access is intended to indicate to the auth system that this list of
identities has "swift_owner" privileges.  A user with admin account access
can do anything the account owner can, including setting privileged headers
-- and thus granting read-only, read-write, or admin access to other users.

The auth system is responsible for making decisions based on these headers,
if it chooses to support their use.

Privileged headers are intended to include X-Container-Read and -Write,
X-Account-Meta-Temp-Url-Key and -Key-2, and of course these account ACL
headers themselves.  Again, it is the auth system's responsibility to
enforce the correct access if the auth system chooses to support account
ACLs.  (If the auth system doesn't support account ACLs, then currently
only the account owner will be able to read or write any account
headers, and other users will only have the existing ways to access
containers and objects.  If future auth systems implement other access
schemes at the account level, they'll all have to play nice together in
order to avoid security issues.)

Change-Id: I2260083f046e911bc5fdaf7728b77746b42a12bd
WIP: teaching tempauth about account acls

Change-Id: I3143c25cc15fd1407287991e36f2ed424e5430ee