> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
>
> 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)?
>
No reason what so ever. However, that didn't seem like what you wanted.
It seemed like you wanted a WC file's permissions set based on the
permissions you want the file to have, and not based on repository
ACL/lock state.
One or the other please, mixing the concepts will just confuse users to
no end.
> > 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? =)
>
For the server side, I completely agree. For the client side, I think we
continue to disagree.
[....]
> > 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.)
>
You keep mixing up server side ACL restrictions with working copy
issues. I'd recommend not making the read-only WC item modification for
security restriction implementations for a Subversion that doesn't
support ACLs.
> > 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.
>
On the server side, I completely agree. On the client side we definitely
disagree. Do you want WC item file permissions to be set arbitrarily by
svn:permissions, or do you want WC item file permissions to be set based
on the server ACL assigned to the item in question.
If you want WC item file permissions assigned based on the ACL in the
Subversion repository, but only in terms of user only read-onlyness. I'm
so with you. If you want WC item file permissions assigned based on
group memberships, and other ACE related issues, I think we begin to
enter fuzzy non-portability land. The Subversion repository ACL -> WC
item file permission mapping needs to be very simple, and very portable.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 22 20:44:29 2002