On Thu, Apr 17, 2003 at 02:52:55PM +1000, Daniel Patterson wrote:
> On Thu, 2003-04-17 at 13:52, mark benedetto king wrote:
> >
> > Oracle has ACLs (well, technically, I think they're capabilities-lists,
> > but that's a different story), even though people with write access to
> > the database could completely subvert them. They're implemented in the
> > database itself, and not in the network layer.
>
> However, how many people have write access to the oracle database files?
> Very few afaik. There is always an oracle "server" process handling
> the interface between the database and client.
>
> With ra_local, there is no such process acting as an interface,
> so *any* client can break any ACL's implemented in the SVN filesystem.
>
> Perhaps ra_local should be reserved for administration and ra_svn
> used by default by all users (over domain sockets locally perhaps)?
If you view Oracle's "connect internal" as analogous to ra_local,
I think things become apparent. A repository administrator is likely
to want to set things up so that very few people could use ra_local,
and most people will use ra_dav, and (when SASL support is added) ra_svn.
>
> This is similar in model to filesystem permissions. Sure, they're
> implemented in the filesystem, but they're *enforced* by the kernel
> (a contantly running process). Users with write access to the raw device
> can bypass whatever they want.
Right.
>
> I'm sure some discussion went into the whole "should we have a
> subversion process running constantly" and the decision is clearly
> not to. However, without one, I'm not sure where any kind of ACL's
> can be enforced....
Essentially, Apache and/or svnserve are the "constantly running
subversion processes".
The existence of ra_local (and "connect internal", and /dev/foo) should not
preclude the implementation of ACLs in the repository abstraction.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 17 16:40:50 2003