The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Thursday, July 03, 2014

Hidden Files in Perforce — Encodo Systems AG

Hidden Files in Perforce — Encodo Systems AG:

'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
 Different error models when scanning / listing directory trees / enumerating
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...).