'via Blog this'
Security model:
- user can see everything - file names, file contents
- user can see file names, but not file contents
- with an error indication if trying to access forbidden file contents
- user can see neither file names nor file contents
- with an error indication "some information was forbidden for you to see"
- with no error indication
and probing for a single filename / identifier.
Any query that might potentially return multiple file objects - e.g. opening by "filename", on a system where there can be multiple file objects with the same name, to be disambiguated by extra metadata (keywords, version numbers) can have the above apply.
filenames are just one form of metadata that can apply to file objects. Other metadata may apply: keywords, version numbers, cryptographic signatures. Should be able to handle situation where some but not all metadata is accessible:
e.g. filename is allowed, file contents access is allowed, but access to certain crypto signatures is not allowed - may not even be allowed to see who has signed things.
Each such metadata instance should have any of the above properties: visible, forbidden with error notification, forbidden silently.
This extends past visibility to permissions such as writeable, appendable.
Similar treatment for "obliterate" - completely removing an object from repository. E.g. removing proprietary code erroneously checked in to an open source project, or vice versa:
Such removal is just like a permissions failure, with no possibility of getting around it (except possibly for backups...).
