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, 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
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. (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.)
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?
Thanks,
-Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 29 01:59:02 2004