At 09:06 PM 7/28/2004, you wrote:
>(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.
It sounds like what we need is an authentication API interface. In an
ACL-type environment, any operation can fail unexpectedly because of
insufficient permissions. The problem seems to be that nobody was thinking
about this when they wrote the current code base, so we're talking about
going through all the files and wrapping every single operation to add
permission checks.
This problem is quite independent of the particular authentication rules,
be they hook scripts, or mod_authz_svn, or property lists, or whatever. In
a way, hook scripts are a kind of poor man's API, which is why I asked
about it originally. But maybe sweeping all the authentication logic
behind an API would make the integration problem less daunting.
On the other hand, it seems like the real message I'm hearing is "Dude,
just use WebDAV, nobody uses svnserve." :-)
>Buffer overflows? Where?
Sorry, apparently the humor didn't survive the e-mail medium. :-)
>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.
Um, a couple remarks on this subject: First, it's ridiculous to create a
situation where installing a piece of software requires revoking everyone's
shell access. Regardless of particular Unix scenarios, from a design
perspective you simply cannot make that kind of assumption. Secondly,
svnserve does offer data protection -- what you do is create a user called
"svn" and run svnserve from that user's account, so the Unix file
permissions prevent any form of access to the repository except through
svnserve. It's not ACL, but it does prevent the grumpy intern from
deleting the repository on his way out the door.
>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.
Where does this fall in the Subversion roadmap? And, where is that
roadmap? I'm having a lot of trouble understanding where everything is
heading.
Thanks again for your comments.
Cheers,
-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 15:50:57 2004