[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Milestone 2: authentication and authorization

From: Jim Blandy <jimb_at_zwingli.cygnus.com>
Date: 2000-12-14 01:08:01 CET

> 2. Authorization: "are you allowed to do something?"
>
> My understanding is that Access Control Lists (ACLs) are the magic
> beasties that determine if certain pieces of data are accessible
> by certain users.
>
> The Subversion filesystem has built-in ACLs; they live as
> non-versioned properties attached to nodes. They can be modified
> like any other properties.
>
> When a DAV process attempts to read or write a node, it presents a
> previously-authenticated username (or group) to the filesystem.
> The filesystem then examines the node's ACL and decides whether to
> allow or deny the action.
>
> * Is that description above correct? Jimb, is this how you
> imagine the filesystem working?

I can promise than in M2, the filesystem will have no code that deals
with authorization.

That said, there are two different approaches to handling this:

- Apparently, you can specify access control lists in Apache
  configuration files. I've been too lazy to look up the details.
  Acknowledging my ignorance, though, I'm wary of this arrangement:

  - First, it seems like an unnecessarily loose coupling between the
    nodes and the controls you're putting on them. When someone
    renames a file, how does the ACL travel along with it? When
    someone deletes a file, shouldn't the ACL go away? Who guarantees
    this coordination? Are changes atomic and recoverable the way
    changes to the filesystem are?

  - What sorts of operations can an Apache-style ACL allow and forbid?
    In Subversion, it makes sense to distinguish between:
    2) permission to change a directory's direct contents (add,
       delete, rename entries)
    1) permission to change the directory's children (bubble-up)
    0) no permission to change either the directory or any of its
       children
    Is that a distinction that fits nicely into Apache ACL's?

  In short, if the ACL's have behaviors dictated by Apache or DAV
  which show through the Subversion client to the user as surprising
  or counterintuitive semantics, I'll be unhappy. (I should wait
  until I know more before complaining, though.)
  
  However, it does avoid creating Yet Another Authorization System.
  Also, people have designed extensions to HTTP (is this part of DAV?)
  for tweaking permissions; it sounds like this arrangement would make
  it trivial for Subversion to work with those extensions.

- We could store ACL's in the filesystem's non-historical node
  properties. This would let us choose whatever node/ACL coupling and
  operation set we find convenient and well-defined. From the Apache
  point of view, however, this could yield a fragmented and
  inconsistent authorization system.

In the former system, it's possible that authorization would be
implemented entirely in mod_dav_svn, with no help from the FS.
Received on Sat Oct 21 14:36:17 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.