Goal: Allow permissions to be stored in the repository and provide a mechanism
      for the client to set them in a portable way in the working copy as well
      as providing an internal security mechanism for Subversion.

      Server-side enforces retrieval of file and modification of files.
      Client-side mimics permissions of repository.

Idea: Have a svn:permissions property.

Problem: Define a value that can be properly interpreted on at least Unix and
         Win32-style permissions.

Unix permissions:
Summary:  u-g-o model (user, group, other).
          Each subset (u,g,o) can have read, write, and execute property.
          Traditionally represented with octets of the following form:
            read:  4
            write: 2
            exec:  1

          Each file has a specific owner and group it belongs to.
          If the uid of the user matches, the user permissions apply.
           If the gid of the user matches, the group permissions apply.
            Else, the other permissions apply.

Note: Some OSes (Solaris) have more complicated and expressive ACL
      mechanisms.
  
Win32 permissions:
Summary:  Access Control Lists (ACL) containing multiple Access Control
          Entries (ACE)
  
  1. Search all ACLs that deny requested access
  2. Search all ACLs for apporval of requested access
  3. If none found, reject.

Types of permissions consisting in a ACE:
  Delete
  Read
  Write
  Append
  Execute
  List Directory
  Add file
  Add subdir
  Traverse
  Delete Child
  Read Attributes
  Write Attributes
  Read Extended Attributes
  Write Extended Attributes

See:
  http://www.netapp.com/tech_library/3079.html
  http://world.std.com/~jimf/papers/nt-security/nt-security.html
          
Proposal:

Mimic ACEs in Subversion by defining a combination of the following values
per file or directory:
  Read
  Write
  Execute
  Delete

Each value may be asserted or negated.

An ACEs is then associated with either a user or group name.

Then, ACEs can be combined together via multiple instances of svn:permissions.

For expansion of ACLs, it is the SVN username (as identified to the server)
not the local client's username that is expanded.

Then, the effective ACEs (Read/Write/Execute/Delete) are mapped to the
client's native permissions format.

Example:

Users:
  jsmith is in users group.
  jdoe is not in users group.
  tadams is not in any group.

Permissions on file foo:
  svn:permissions "jsmith:read,delete,write,execute"
  svn:permissions "jdoe:execute,!write"
  svn:permissions "users:read"
  svn:permissions "everyone:read"

Server modifications:
  jsmith:
    Can read, delete or modify the file and properties
  jdoe:
    Can read file and properties
  tadams:
    Can read file and properties
 
Unix-side working copy resolution:

  jsmith's view:
    rwxr--r-- foo
  jdoe's view:
    r-x---r-- foo 
    (note: r bit propogates to user!  everyone's props must be in user.)
  tadams's view:
    r-----r--

Win32 working copy resolution:
  jsmith's view:
    Delete, Read, Write, Append, Execute, Read Attr, Write Attr, Read EA,
    Write EA
  jdoe's view:
    Read, Execute, Read Attr, Read EA
  tadams's view:
    Read, Read Attr, Read EA
 
Question: How do we define groups since they are server-side?
          (Must define the group somewhere - perhaps walk up tree at each
           directory looking for a group definition mechanism.)
Question: How do we differentation what is a group and what is a user?
          (Define notation for group ACE vs. user ACE.)
Question: How do we resolve unknown/unrecognized users?
          (Define a special user/group name as catch-all.)
Question: Should we inherit recursive nature of Win32 ACLs?
          (First guess, yes, but may not be desired due to performance.)
Question: How about IP-based security?
          (Only for server-side.)
Question: Should everyone ACL apply to o field in Unix?
          (Perhaps.)
Question: What if working-copy permissions don't necessarily correspond to
          repository-access permissions?
          (i.e. file should be checked out read-only, but user can modify it.)
Question: What about sticky bits?
          (Does Win32 have this concept?)