[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Re: svn commit: rev 3010 - trunk/notes

From: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2002-08-22 19:13:18 CEST

On Thu, Aug 22, 2002 at 12:49:26AM -0700, Bill Tutt wrote:
> I disagree. There is a very weak correlation. A SCM's security model
> should be designed to handle SCM issues, and not to represent file
> system security semantics.

My point is that the working copy *can* mimic the user's view
of the system. If the user can't write to the SCM, why should
we allow them to write to the WC (by default)?

> That's right, a decent ACL model has been punted from 1.0. I'm not
> thrilled about it, but I don't have time to help fix the problem either.
> :(

Right, but it doesn't mean that we (err, I) can't start working on it
now. Obviously, there's a lot we need to hash out.

I'm not silly enough to think a full ACL model is going to happen
overnight. But, I think we're going to have to deal with it at
some point. Why not now? =)

> I disagree partially here. Different SCM lock models typically make
> files read only by default. I think Subversion will eventually have some
> kind of lock model that will make this kind of thing happen.

And, my point is that when the local copy is read-only (via SCM
permissions or advisory locks), their view of the system is
read-only - they can't write - therefore, the WC should reflect that.
(Again, make this optional if you like.)

> I agree. I'm not terribly happy with not having a decent security story
> for Subversion's 1.0 release, but at least users can roll their own
> security restrictions.

I think the ACLs within httpd-2.0 are decent at letting people have
raw access, but as we've seen, it's hard to grant people access
to only a portion of the repository.

So, httpd-2.0 can prohibit who sees the system, but SVN can provide
much finer-grained locking on its side.

FWIW, I believe users can't roll their own security restrictions
because of how libsvn_wc handles the files. You would need to run
a fixup after every operation. I'd rather spend my time trying to
fix this within SVN rather than write a hack that will be thrown
away. (And, to Dan's point, no, I'm not writing a client. I'm
simply using the std client.)

> Yep. Unfortunately for Subversion 1.0, this same point will currently
> apply.

True, but nothing (should) prevent us from starting the effort now.
Perhaps the CollabNet guys may not pay the best attention to this
discussion, but if by divine intervention, you and I actually agree
on a ACL design that might work, then that's a starting place for
others to jump in to the conversation and for me to go off and start
trying to implement it.

As I said, I have a need for this (specifically on the client-side
and I believe the ASF will need the server-side if it uses SVN). I
believe I might have enough time to scratch this itch - I dunno,
but I'd like to start sketching out ideas. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 22 19:13:52 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.