Pete Gonzalez wrote:
> At 06:00 PM 7/28/2004, you wrote:
>
>>> my proposal: Instead of worrying about hook scripts, why don't we just
>>> expand svnserve's authentication model? In other words, we can
>>> implement
>>> for svnserve a small subset of what WebDAV is doing. This should be an
>>> inexpensive way to extend the old model until a proper ACL mechanism
>>> is designed. I mean shit, svnserve could probably do this using
>>> properties. So... how much work would this be? :-)
>>
>>
>> I have no idea how much work it would be to do that, but I suspect it
>> would touch a significant part of our FS library -- effectively
>> duplicating exactly the same amount of work (and intrusiveness) as
>> needed for read hooks -- or real ACLs, for that matter.
>
>
> No no, I mean these checks would be implemented in serve.c (or
> thereabouts),
> as opposed to integrating them directly into the repository/filesystem
> libraries. Maybe I'm being overly simplistic here,
Yup :-)
> but this is the picture
> in my head (granted I haven't looked very closely at the code):
>
> A. svn --> Apache --> Repository --> FileSystem
>
> B. svn --> svnserve --> Repository --> FileSystem
These two scenarios aren't even remotely comparable as far as access
control is concerned.
(A) uses the WebDAV and DeltaV extensions to the HTTP protocol. This
protocol is stateless, and the extensions are such that every path that
the client wishes to read or modify is noted explicitly in HTTP request
headers, which mod_authz_svn can check with (almost) no knowledge of how
Subversion actually does its thing.
(B) uses a proprietary, stateful protocol that basically does nothing
more than marshal Subversion's repository-access API calls (_not_
libsvn_repos or libsvn_fs) through a socket connection. Now it would be
possible to do the semantic interpretation necessary for access control
in the unmarshaler in svnserve, but that would a) duplicate some of the
work that other libraries already do, and b) require effort comparable
to implementing access control in the repository or FS layer, as I said
before.
> C. svn --> Repository --> FileSystem
>
> Inside the "Apache" box is a fairly elaborate security model. Inside
> the "svnserve" box is a little text file containing some plaintext
> passwords and a few buffer overflows for good measure.
Buffer overflows? Where?
> (Scenario C
> is the fabled "SSH authentication" case from CVS, where you pass
> a triple security check and retinal scan to end up in a dimly lit
> prison cell, wherein you can bend the Berkley database over a table
> and do whatever you like, but everyone knows it was you.)
This doesn't actually happen quite like that in Subversion, because the
actual scenario is
svn --> ssh --> svnserve --> Repository --> FileSystem
That is, you use ssh for tunneling svnserve's socket connection, not for
login onto the server. In fact, CVS does things like that, too.
Of course, if you do allow users to log onto the server, whether via SSH
or some other mechanism, neither SVN or CVS can do anything to protect
your data.
> So my question is: If we just want to add a few more security tests
> inside the "svnserve" box, why would this involve the Repository or
> FileSystem boxes?
My point is that if we do _not_ implement access control there, we'll be
duplicating work in svnserve that we intend to do in Repos/FS in any
case. So it's better to do this once in the right place, than to start
with a hack that won't save much time in the short term and will double
the effort in the long term.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 29 03:07:02 2004