> 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