Pete Gonzalez wrote:
> 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.
No, not at all. Any operation can _already_ fail because of insufficient
permissions (witness that mod_authz_svn works). There's no need for any
wrapping, and you definitely do not want to check for permissions up front.
> This problem is quite independent of the particular authentication
> rules, be they hook scripts, or mod_authz_svn, or property lists, or
> whatever.
You're confusing authentication with authorization. Hook scripts,
mod_authz_svn, etc. implement authorization -- access contril, if you
will. Authentication is a different can of worms which the SVN
repository and filesystem intentionally ignore.
> 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.
s/authorization/authentication/ and I agree, of course.
> On the other hand, it seems like the real message I'm hearing is
> "Dude, just use WebDAV, nobody uses svnserve." :-)
Bah. I'd estimate about 50% of our users live on svnserve.
>> Buffer overflows? Where?
>
>
> Sorry, apparently the humor didn't survive the e-mail medium. :-)
Well, you scared me because buffer overflows in a server are a serious
matter.
>> 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.
That's true. What I meant was that, once someone has shell access to the
machine, it's much, much easier for them to somehow grab root access if
they're really determined to do that. Or rather, how much you trust your
users has nothing to do with Subversion. :-)
>> 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.
I'll let others comment about roadmaps, but we are currently discussing
ACLs and locking for inclusion in one of the upcoming releases
(certainly in the 1.x series). That discussion got sidetracked a bit
because of the 1.1 release effort, and because I'm chronically short on
time (I've been promising the ACL design doc for ages... :-( )
> Thanks again for your comments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 29 18:30:04 2004