You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/08/22 06:38:58 UTC
Re: svn commit: rev 3010 - trunk/notes
On Thu, Aug 22, 2002 at 01:12:03AM -0500, jerenkrantz@tigris.org wrote:
> Author: jerenkrantz
> Date: 2002-08-22 01:11:42 -0500 (Thu, 22 Aug 2002)
> New Revision: 3010
>
> Modified:
> trunk/notes/permissions
> Log:
> * notes/permissions: Expand scope to also include ACLs for SVN itself. Add
> notes on Win32 ACL structure. Expand to give ideas of how this might
> work.
Yes, I'm conceptually expanding this to consider SVN enforcing ACLs
in modifications applied to the repository.
I think there is a strong correlation between client-side permissions
and the server-side permissions. Therefore, we should at least
examine how this might effect a hypothetical SVN server's security
model. I tried to look to see if there was any documentation on a
security model and didn't see any. (Truth be told, SVN can't really
rely on httpd-2.0's ACL model as it just isn't expressive enough for
a SCM system.)
If a local copy has read-only permissions, then I believe the same
should be true of that user's view of the repository.
I think that the server-side and client-side enforcement of the
security do not have to be implemented at the same time. Therefore,
we could implement the client-side permissions and then subsequently
add the server-side enforcement. (Or, vice versa.)
However, I think leaving a permissions model outside of the SCM
system will be harmful if we don't address it and say that everyone
must roll their own security model.
I look at the craziness of the cvs_acls.pl script that the ASF
uses and I think it'd be much cleaner if SVN addressed it head-on.
The rise of such tools indicates that CVS is lacking here. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re: Re: svn commit: rev 3010 - trunk/notes
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Aug 22, 2002 at 10:46:48AM -0700, Bill Tutt wrote:
> 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.
Who said I couldn't change my mind? =)
I now see how a model based on a Subversion with ACLs could give
enough knowledge to the client on how to achieve the same goal.
As you state later, yes, it gets fuzzy. But, that's the fun part.
> One or the other please, mixing the concepts will just confuse users to
> no end.
Users? What users? =)
> 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.
Fair enough. So, how about we first try to tackle supporting
something like WebDAV ACL in Subversion? (My one concern is whether
anyone has tried to use WebDAV ACLs yet.)
Once that is complete (ha!), we can revisit the concept of providing
a mechanism where the client utilizes the server-side ACLs on the
local filesystem in *some* manner.
I've already scratched my immediate need and it doesn't seem like
anyone else has an even remotely similar use case, so I'm willing
to drop it for now. Yet, it wouldn't shock me that there *are*
people who use it in the manner I describe or could use it -
portability on Win32 be damned. It just makes so much sense to me
that it befuddles me that others don't see this.
Again, I wonder if we're too focused on only source code in the
repository. It'd be awesome to store installations of SW in SVN
itself, like so:
svn co http://localhost/apache/2.0.40 apache
*poof* it's my 2.0.40 apache setup.
rm -rf apache
svn co http://localhost/apache/1.3.26 apache
*poof* it's my 1.3.26 apache setup.
vi apache/conf/httpd.conf
svn ci
apache/bin/apachectl start
*poof*
Those are the types of cases I'm thinking of. And, for those, yes,
I still think we need to be able to have fine-grained WC permission
of entities in the repository. Portability isn't the concern here
(mainly because binaries are checked in) - functionality is.
Yet, no one else seems to like this, so I'll table it for now and
focus on server-side permissions...
> 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.
Agreed. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
re: ACLs/WC permission setting
Posted by Bill Tutt <ra...@lyra.org>.
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
>
> As I said before, I needed a mechanism for WC permissions. I've
> already coded it up and it works, but obviously, no one is interested
> in seeing that in SVN itself. *sigh* I think you're missing a
> feature that people *might* want (it's opt-in).
>
I've gotten confused over your various emails. Do you want to set
permissions in the WC based on the permissions you'd like the file to
have when it's "deployed", or do you want to set permissions in the WC
based on Subversion ACL data? I've been trying to communicate that I
think those two goals are self contradicting. (Besides replicating
filesystem permissions completely is a completely and utter non-portable
rat hole, and I'm not terribly intereseted/thrilled about starting down
slippery rat holes.)
I actually approve of the 2nd goal, it's the first goal that makes me
all nervous.
> But, I'm content to start trying to tackle the WebDAV ACL. At least
> that way, I can start to potentially refine what would make the WC
> permissions better. Hopefully, that'll please Bill. -- justin
>
Please, don't think you have to please me. I'm just very vocal about
design stuff. You have to please other folks as well. :)
In terms of WebDAV ACL stuff, I think there are a couple of questions
that need to be answered first.
* Are WebDav ACLs version independent, version dependent, or up to
repository choice?
* What inheritance model should Subversion support? If so, how?
* Should ACLs themselves be versioned?
* What sub/superset of WebDAV privileges should Subversion have, and how
should they map to WebDav's privilege model?
If you're around, hop on IRC and maybe we can figure out quickly why I'm
confused about what you want to get out of this WC permission stuff.
Thanks,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3010 - trunk/notes
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Aug 22, 2002 at 11:33:46AM -0700, Greg Stein wrote:
> And note that (IMO) any ACL support should begin with WebDAV ACL support in
> Apache itself.
My impression based on the WebDAV ACL spec was that enforcement is
based on properties. Therefore, a mod_dav wouldn't *need* to be
involved. But, I do need to read up on the WebDAV ACL draft and
then look at mod_dav and see what would have to change there.
And, partly, in order to add WebDAV ACL support to mod_dav, it needs
something that uses ACLs to provide impetus. I volunteer Subversion.
> > If a clean, simple design emerges well before 1.0, perhaps it can even
> > get into 1.0.
>
> Let's stress "clean" and "simple" :-).
Unlikely for 1.0, but I don't think that the collective 1.0 effort
will be impacted much if I go off and see what it would take and
perhaps start a coding effort. It's not like I'm that important.
(Which is why I don't mind if the CollabNet group doesn't pay much
attention to this now.)
> [ I'm hoping most SVN developers here agree that getting 1.0 out now is a
> higher priority than more features ]
It's 1.0 for me as I'm using it.
As I said before, I needed a mechanism for WC permissions. I've
already coded it up and it works, but obviously, no one is interested
in seeing that in SVN itself. *sigh* I think you're missing a
feature that people *might* want (it's opt-in).
But, I'm content to start trying to tackle the WebDAV ACL. At least
that way, I can start to potentially refine what would make the WC
permissions better. Hopefully, that'll please Bill. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3010 - trunk/notes
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 22, 2002 at 11:59:47AM -0500, Karl Fogel wrote:
> Justin Erenkrantz <je...@apache.org> writes:
> > 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.
>
> Oh, we're paying attention, just not participating (due to lack of
> time, not interest).
Right.
And note that (IMO) any ACL support should begin with WebDAV ACL support in
Apache itself.
> If a clean, simple design emerges well before 1.0, perhaps it can even
> get into 1.0.
Let's stress "clean" and "simple" :-).
[ I'm hoping most SVN developers here agree that getting 1.0 out now is a
higher priority than more features ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3010 - trunk/notes
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Justin Erenkrantz <je...@apache.org> writes:
> 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.
Oh, we're paying attention, just not participating (due to lack of
time, not interest).
If a clean, simple design emerges well before 1.0, perhaps it can even
get into 1.0.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: Re: svn commit: rev 3010 - trunk/notes
Posted by Bill Tutt <ra...@lyra.org>.
> 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
Re: Re: svn commit: rev 3010 - trunk/notes
Posted by Justin Erenkrantz <je...@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)?
> 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
RE: Re: svn commit: rev 3010 - trunk/notes
Posted by Bill Tutt <ra...@lyra.org>.
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
>
> On Thu, Aug 22, 2002 at 01:12:03AM -0500, jerenkrantz@tigris.org
wrote:
> > Author: jerenkrantz
> > Date: 2002-08-22 01:11:42 -0500 (Thu, 22 Aug 2002)
> > New Revision: 3010
> >
> > Modified:
> > trunk/notes/permissions
> > Log:
> > * notes/permissions: Expand scope to also include ACLs for SVN
itself.
> Add
> > notes on Win32 ACL structure. Expand to give ideas of how this
might
> > work.
>
> Yes, I'm conceptually expanding this to consider SVN enforcing ACLs
> in modifications applied to the repository.
>
> I think there is a strong correlation between client-side permissions
> and the server-side permissions. Therefore, we should at least
> examine how this might effect a hypothetical SVN server's security
> model.
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.
> I tried to look to see if there was any documentation on a
> security model and didn't see any. (Truth be told, SVN can't really
> rely on httpd-2.0's ACL model as it just isn't expressive enough for
> a SCM system.)
>
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.
:(
> If a local copy has read-only permissions, then I believe the same
> should be true of that user's view of the repository.
>
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.
> I think that the server-side and client-side enforcement of the
> security do not have to be implemented at the same time. Therefore,
> we could implement the client-side permissions and then subsequently
> add the server-side enforcement. (Or, vice versa.)
>
Assuming that the models should be that similar, this definitely is so.
> However, I think leaving a permissions model outside of the SCM
> system will be harmful if we don't address it and say that everyone
> must roll their own security model.
>
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 look at the craziness of the cvs_acls.pl script that the ASF
> uses and I think it'd be much cleaner if SVN addressed it head-on.
> The rise of such tools indicates that CVS is lacking here. -- justin
>
Yep. Unfortunately for Subversion 1.0, this same point will currently
apply.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org