[Subversion Wiki] Update of "InRepoAuthz" by BenReser

[Apache subversion Wiki <co...@subversion.apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "InRepoAuthz" page has been changed by BenReser:
http://wiki.apache.org/subversion/InRepoAuthz

Comment:
First stab at designing authz files stored inside the repository (not finished need to go to dinner)

New page:
== Design: Authz Stored Inside the Repository ==

It is desirable to store Authz files inside a Subversion Repository (potentially the same repository the file is written to protect).  By placing the file in Subversion you gain versioning and the audit trail that comes with it.  Additionally, it simplifies replication since your Authz file is no longer out of band.

This can already be achieved by writing hook scripts that export the Authz file from Subversion on commit.  However, it may be undesirable to use a hook script in cases where Authz is being managed by a 3rd party GUI and requiring a hook script in every installation would potentially conflict with other hook scripts.

=== Behavioral Specification ===

The Authz file may be specified in one of four forms a location inside a repository, a relative path within the repository being accessed, a absolute file path outside of the repository or a relative file path outside of the repository.  The file would then be read from the location specified, parsed and the results cached for a single connection as is already the case with the existing external file path implementation.  There is one exception to the current behavior which is the --config-file option to svnserve which causes the Authz file specified in the config file to be cached for the entire time svnserve runs, this one case is troublesome.

These four forms allow for Authz to be used out of the same or a different repository and in the case of the SVNParentPath mod_dav_svn option or -d option to svnserve allows for each repository to contain its Authz file.

=== Format of the Authz Path ===

The four forms would take the following formats:

* `file:///repo/authz` : A string starting with `file://` followed by the absolute path to the repo followed by the path within the repo to the authz file, identical to what you'd provide to the svn client's cat command if you wanted to cat the file.

* `^/authz` : A string starting with ^/ and followed by the relative path within the repo.  ^/ would be replaced by the full path to the current repo's root.  This is the same as the path style used within the Subversion client itself to reference relative URL paths.

* `/path/authz` : A fully qualified path to the AuthZ file.  On Unix systems it will likely start with / and on Windows would start with a drive letter.

* `path/authz` : A relative path to the AuthZ file.  Does not start with a / or a drive letter.  When used with mod_authz_svn the path would be resolved relative to the ServerRoot of the httpd server.  When used with svnserve it would be resolved relative to the conf dir of the repository.  If you wished to reference a relative path which started with `^` you could preceed it with a . e.g.: `./^/authz`

=== SVNParentPath Operation ===

When used with SVNParentPath in the case of mod_dav_svn or -d in the case of svnserve it may be desirable to always use the Authz file at the same path within the repository being accessed.  At current svnserve and mod_authz_svn do not have a uniform way of configuring Authz.

...Incomplete needs to finish writing up how we behave here since I think we want to make some behavior changes...

=== Security ===

One obvious question is the security of the Authz file once it is stored within the repository.  This would be left up to the user to implement via the Authz file themselves.  Appropriate documentation would be written.  In the case of an Authz file being committed that prevented all access to a repository it could be repaired with ra_local since Authz is not applicable there.

=== Performance ===

Until this is implemented on an experimental branch performance will not be clear.  However, in the case where the Authz file is in the same repo as the repo which it is protecting we should be able to use the repository connection for both retrieving the Authz file and the actions of the client, which should minimize the overhead.  Server side caches will also aid with performance and if the data is already cached in memory should result in similar performance to a file system hosted Authz file which would likely be cached by the OS in memory.

However, as with all features it will carry some degree of overhead.

=== What this is not ===

This design is not a long term solution to ACLs.  Building in ACLs as we might choose to do with FS2 would still be highly desirable.  This is nothing more than an expansion of the existing Authz capabilities to allow easier administration.

It is also not a good general model to move things like hook scripts into the repository.  While the Authz file is only used by mod_authz_svn and svnserve (both of which have direct access to the repository) the hook scripts are executed by the operating system on behalf of the Subversion server and would have to be written to the file system.