You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2002/05/22 23:07:48 UTC
libsvn_auth
Back in March, or maybe earlier, when I was out in Chicago, we talked about
shifting a bunch of the auth code out into "libsvn_auth". The specific
clients for this library would be RA (performing interactions between the
"server" and the auth information) and the user client (e.g. clients/cmdline
for setting up the auth info). An opaque object would be passed into
libsvn_client for later use by the underlying RA layer.
The rationale for yanking it out into a separate library is that, right now,
we have auth info kind of associated with RA (the various vtables), and also
a bunch of stuff in CLIENT and clients/cmdline, also very specific. But as
we add more auth types (think GUI clients, and certs), it is going to have a
wide impact.
I'm hoping that we can shove most of the auth-related stuff down into
libsvn_auth to help encapsulate it a bit more, provide some nicer APIs, and
to localize future auth work and bug fixes.
Any thoughts? Objections? etc
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: libsvn_auth
Posted by Ben Collins-Sussman <su...@collab.net>.
"Glenn A. Thompson" <gt...@cdr.net> writes:
> Hey:
>
> Greg Hudson wrote:
>
> > Is that "authentication" or "authorization"?
>
> Boy do I want to know more about this.
>
In a nutshell:
* gstein is talking about "authentication". There is authentication
code dribbled throughout our client app, libsvn_client, and
libsvn_ra_*. Ultimately, it's all just a way of getting
authentication data into neon, so neon can repsond to
authentication challenges from apache. This is the stuff gstein
wants to split out.
* authorization is currently all via httpd.conf, or via repository
pre/post-commit 'hook' scripts. After 1.0, we'll be working on
ACLs within the svn filesystem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Authz, WAS: RE: libsvn_auth
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
> Hey
> Anyhow, not targetted at Glenn in particular, if you haven't read the ACL threads
> in the archives, please try to locate and read them before following up. That
> saves a lot of duplicated discussion.
>
Sorry, thats the second thread I've hijacked this week.
I must do better research.
Back to my hole:-)
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ACLs in Subversion (was: Re: Authz)
Posted by Alan Langford <ja...@ambitonline.com>.
At 2002/05/23 23:54 -0400, Greg Hudson wrote:
>If we do want to record a history of ACL changes, then a possible
>solution is to have an acl file somewhere in the Subversion file space
>(similar in principle to the Apache access control config file), and
>then when you make a copy, the filesystem magically edits the acl file
>so that the acl on the new node matches the acl on the old node. That's
>kind of weird, though, and calls into question how things work when you
>want to make a copy and edit the acl file at the same time.
1) Don't version the ACLs.
2) Keep ACLs in a separate "versioning space". Aren't changes to the ACLs
orthogonal to changes to the rest of the file base?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ACLs in Subversion (was: Re: Authz)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2002-05-23 at 23:46, Glenn A. Thompson wrote:
> OK thats what I hoped you meant. Read can be exposed. Not write. But it was
> readable at 9 before anyway. I think this is reasonable and consistant.
Consistent, yes. Reasonable, no. You need to be able to retcon ACL's
when:
* You discover that you forgot to set a restrictive ACL on some
proprietary source you brought online last week.
* You hire someone new and need to give them read access to the change
history of the proprietary source code.
The latter problem can be solved if we implement a group system inside
Subversion (an ACL would point to a group, and the group could be
changed without changing the ACL itself), but man, that's a lot of hair.
One question is how important it is to record a history of ACL changes.
If it's not, we can simply provide an interface for changing properties
(or some concept which is "just like properties") on old revisions of a
node and have done with it.
If we do want to record a history of ACL changes, then a possible
solution is to have an acl file somewhere in the Subversion file space
(similar in principle to the Apache access control config file), and
then when you make a copy, the filesystem magically edits the acl file
so that the acl on the new node matches the acl on the old node. That's
kind of weird, though, and calls into question how things work when you
want to make a copy and edit the acl file at the same time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ACLs in Subversion (was: Re: Authz)
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
>
Hey
>
> 1. revision 9 has no ACLs.
> 2. I add an ACL to BAR and commit. I now have rev 10.
> 3. Random Joe comes along and can't read BAR
> 4. he falls back to rev 9 and reads BAR since it has no ACL.
OK thats what I hoped you meant. Read can be exposed. Not write. But it was
readable at 9 before anyway. I think this is reasonable and consistant. The
default mechanism being kicked around could come in handy for this. Default the ACL
on the parent dir so that the first version always gets an ACL.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ACLs in Subversion (was: Re: Authz)
Posted by Greg Stein <gs...@lyra.org>.
On Thu, May 23, 2002 at 11:15:02PM -0400, Glenn A. Thompson wrote:
>...
> > * use ACLs that are attached to an item?
> > - pro: survives copies
> > - con: back up one revision to avoid the ACL
>...
> I don't see how backing up avoids the ACL in any significant way? But this is
> tough to get the ol brain around.
1. revision 9 has no ACLs.
2. I add an ACL to BAR and commit. I now have rev 10.
3. Random Joe comes along and can't read BAR
4. he falls back to rev 9 and reads BAR since it has no ACL.
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: ACLs in Subversion (was: Re: Authz)
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
> Right.
>
> ACLs are a complete and total bitch when you have a versioning repository
> with copy-by-reference.
>
> * use ACLs that are path-based?
> - pro: works great for "going back in time" to protect content
> - con: fails once you make a copy
>
> * use ACLs that are attached to an item?
> - pro: survives copies
> - con: back up one revision to avoid the ACL
>
> At some point, we'll need to find a solution. But for now, I'm going to keep
> my head from exploding and ignore the problem.
>
Well can't we make it explode just a little bit? :-)
I don't see how backing up avoids the ACL in any significant way? But this is
tough to get the ol brain around.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
ACLs in Subversion (was: Re: Authz)
Posted by Greg Stein <gs...@lyra.org>.
On Thu, May 23, 2002 at 10:17:08PM +0200, Branko Äibej wrote:
> Sander Striker wrote:
> >As for "it has to be in the repos to work", yes, true. I think we came up
> >with implementing it using svn:acl properties. This is what I would like to
> >see as a priority item _post_ 1.0.
>
> Sadly, that won't work. You want to be able to change the ACL on an old
> version, so props aren't appropriate.
Right.
ACLs are a complete and total bitch when you have a versioning repository
with copy-by-reference.
* use ACLs that are path-based?
- pro: works great for "going back in time" to protect content
- con: fails once you make a copy
* use ACLs that are attached to an item?
- pro: survives copies
- con: back up one revision to avoid the ACL
At some point, we'll need to find a solution. But for now, I'm going to keep
my head from exploding and ignore the problem.
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: Authz, WAS: RE: libsvn_auth
Posted by Branko Čibej <br...@xbc.nu>.
Sander Striker wrote:
>As for "it has to be in the repos to work", yes, true. I think we came up
>with implementing it using svn:acl properties. This is what I would like to
>see as a priority item _post_ 1.0.
>
>
Sadly, that won't work. You want to be able to change the ACL on an old
version, so props aren't appropriate.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Authz, WAS: RE: libsvn_auth
Posted by Sander Striker <st...@apache.org>.
> From: Glenn A. Thompson [mailto:gthompson@cdr.net]
> Sent: 23 May 2002 10:30
[...]
>> There are some issues with respect to doing fine grained access control
>> with Apache. Greg Stein and I tried to come up with an Apache configuration
>> that did fine grained access control, but we got bitten by the so
>> called '$svn' url.
>
> Not sure what you mean here, but what halted me was the idea that a given URL
> "name" can point to different nodes over time. wooaa. I planned on the ACLs
> being contained outside subversion at first. No No No. Once I thought about it,
> I freaked and stopped. It has to be in the Repos to work.
This was to see if we could get fine grained access control going without
implementing anything in subversion, so that if people really wanted it, they
could have it by doing it through Apache configuration.
And yes, you are right, several Locations can point to the same repository,
which would be a nightmare when it comes to access control. However, this
isn't really a problem since this is done in the same apache configuration
file where you took great care in doing access control. It would be stupid
to shoot yourself in the foot.
As for "it has to be in the repos to work", yes, true. I think we came up
with implementing it using svn:acl properties. This is what I would like to
see as a priority item _post_ 1.0.
Anyhow, not targetted at Glenn in particular, if you haven't read the ACL threads
in the archives, please try to locate and read them before following up. That
saves a lot of duplicated discussion.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn_auth
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
> Hey
> Ah, another person getting burned by the outdated design doc ;)
> Can we please update the doc? Or at least remove the auth/authz
> section and place a TBD in there?
That would be nice. TBD would suffice:-)
>
>
> There were several quite long threads about this on the mailinglist.
> Please search the archives and seek them out. ACLs are not scheduled
> for 1.0 IIRC. We do have consensus with respect to needing ACLs at some
> point though.
I'll dig into this when I get back to this issue.
>
>
> > I actually started to develop an Apache 2.0 module to handle all of this
> > outside of subversion. I have stopped for the time being as It seemed
> > like I was heading in the wrong direction. I need it for something else
> > I'm doing, so I will complete it at some point.
>
> There are some issues with respect to doing fine grained access control
> with Apache. Greg Stein and I tried to come up with an Apache configuration
> that did fine grained access control, but we got bitten by the so
> called '$svn' url.
Not sure what you mean here, but what halted me was the idea that a given URL
"name" can point to different nodes over time. wooaa. I planned on the ACLs
being contained outside subversion at first. No No No. Once I thought about it,
I freaked and stopped. It has to be in the Repos to work.
>
>
> > Please Please clarify this whole thing for me folks.
>
> The current status is that ACLs are put on hold for now. But ofcourse
> anyone with enough time could provide patches ;)
I guess what I'm asking is: do you guys have a design of some sort for ACLs. Or
even a loose set of requirements.
As for patches:-)
I'm currently working on building a SQL FS. Yes, I really am.
Patches are a ways off. I'm spinning up a little slower than I had hoped but
I'm making progress.
I changed my approach when cmpilato started working on the skel separation and I
learned of the unbounded key issue.
That reminds me, I need to update. It's been hours. Mike could had checked in
several hundred files by now:-)
So while all that is fleshing out, I'm playing with how to ask the basic
ancestry/hierarchy questions of a SQL store and what that SQL store should look
like. Once I can defend my approach "OH and I have one:-)", I will post ERDs
and perhaps a few SQL scripts to demonstrate the basic query accesses I will
need. I will most likely have more tables than the BDB FS has.
woooaaa sorry to switch subjects on you.
Thanks for the response,
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: libsvn_auth
Posted by Sander Striker <st...@apache.org>.
> From: Glenn A. Thompson [mailto:gthompson@cdr.net]
> Sent: 23 May 2002 07:57
> Hey:
>
> Greg Hudson wrote:
>
> > Is that "authentication" or "authorization"?
>
> Boy do I want to know more about this.
>
> After reading the design document some time ago, I assumed that
Ah, another person getting burned by the outdated design doc ;)
Can we please update the doc? Or at least remove the auth/authz
section and place a TBD in there?
> Subversion (Server side) provided for Authorization only.
> However, I've only been able to find authentication code and that code
> appeared to be client stuff only. I haven't found any code implementing
> 7.2.1.2 of the design document. A previous thread lead me to believe
> that commit hooks are the way to handle authorization vs what is
> discussed in 7.2... The only authorization I've been able to track down
> was the Apache based methods. Does Subversion authorize for local
> access? Hooks are fine for me but the Subversion MO makes me think that
> there is an API I'm missing. What about the ACLs I've seen mentioned in
> a few threads?
There were several quite long threads about this on the mailinglist.
Please search the archives and seek them out. ACLs are not scheduled
for 1.0 IIRC. We do have consensus with respect to needing ACLs at some
point though.
> I actually started to develop an Apache 2.0 module to handle all of this
> outside of subversion. I have stopped for the time being as It seemed
> like I was heading in the wrong direction. I need it for something else
> I'm doing, so I will complete it at some point.
There are some issues with respect to doing fine grained access control
with Apache. Greg Stein and I tried to come up with an Apache configuration
that did fine grained access control, but we got bitten by the so
called '$svn' url.
> Please Please clarify this whole thing for me folks.
The current status is that ACLs are put on hold for now. But ofcourse
anyone with enough time could provide patches ;)
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn_auth
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey:
Greg Hudson wrote:
> Is that "authentication" or "authorization"?
Boy do I want to know more about this.
After reading the design document some time ago, I assumed that
Subversion (Server side) provided for Authorization only.
However, I've only been able to find authentication code and that code
appeared to be client stuff only. I haven't found any code implementing
7.2.1.2 of the design document. A previous thread lead me to believe
that commit hooks are the way to handle authorization vs what is
discussed in 7.2... The only authorization I've been able to track down
was the Apache based methods. Does Subversion authorize for local
access? Hooks are fine for me but the Subversion MO makes me think that
there is an API I'm missing. What about the ACLs I've seen mentioned in
a few threads?
I actually started to develop an Apache 2.0 module to handle all of this
outside of subversion.. I have stopped for the time being as It seemed
like I was heading in the wrong direction. I need it for something else
I'm doing, so I will complete it at some point.
Please Please clarify this whole thing for me folks.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn_auth
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Thu, 2002-05-23 at 22:34, Ben Collins-Sussman wrote:
> > Greg Hudson <gh...@MIT.EDU> writes:
> > > Keeping the name "libsvn_auth" is reasonable, but please do try to use
> > > the full word "authorization" instead of the abbreviation "auth" in
> > > comments.
>
> > Well, now *I'm* getting confused. In my last message, I insisted that
> > libsvn_auth stood for "authentication", since we only have
> > authentication code in the client right now, not authorization code.
> > So which is it?
>
> Sorry, I wrote the wrong word. (Mmm, egg.)
*phew*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn_auth
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2002-05-23 at 22:34, Ben Collins-Sussman wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
> > Keeping the name "libsvn_auth" is reasonable, but please do try to use
> > the full word "authorization" instead of the abbreviation "auth" in
> > comments.
> Well, now *I'm* getting confused. In my last message, I insisted that
> libsvn_auth stood for "authentication", since we only have
> authentication code in the client right now, not authorization code.
> So which is it?
Sorry, I wrote the wrong word. (Mmm, egg.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn_auth
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Thu, 2002-05-23 at 18:16, Greg Stein wrote:
> > On Wed, May 22, 2002 at 10:50:50PM -0400, Greg Hudson wrote:
> > > Is that "authentication" or "authorization"?
> >
> > Is that a questions, or are you suggesting the name should change for
> > clarification?
>
> It was mostly a question. I read your initial message carefully and
> couldn't figure out which you were talking about.
>
> Keeping the name "libsvn_auth" is reasonable, but please do try to use
> the full word "authorization" instead of the abbreviation "auth" in
> comments.
Well, now *I'm* getting confused. In my last message, I insisted that
libsvn_auth stood for "authentication", since we only have
authentication code in the client right now, not authorization code.
So which is it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn_auth
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2002-05-23 at 18:16, Greg Stein wrote:
> On Wed, May 22, 2002 at 10:50:50PM -0400, Greg Hudson wrote:
> > Is that "authentication" or "authorization"?
>
> Is that a questions, or are you suggesting the name should change for
> clarification?
It was mostly a question. I read your initial message carefully and
couldn't figure out which you were talking about.
Keeping the name "libsvn_auth" is reasonable, but please do try to use
the full word "authorization" instead of the abbreviation "auth" in
comments.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn_auth
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 22, 2002 at 10:50:50PM -0400, Greg Hudson wrote:
> Is that "authentication" or "authorization"?
Is that a questions, or are you suggesting the name should change for
clarification?
"libsvn_authn" would be the first obvious one, but I like plain "auth"
better...
Thanks,
-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: libsvn_auth
Posted by Greg Hudson <gh...@MIT.EDU>.
Is that "authentication" or "authorization"?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn_auth
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> I'm hoping that we can shove most of the auth-related stuff down into
> libsvn_auth to help encapsulate it a bit more, provide some nicer APIs, and
> to localize future auth work and bug fixes.
Go go go! +1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: libsvn_auth
Posted by Sander Striker <st...@apache.org>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: 23 May 2002 01:08
> Back in March, or maybe earlier, when I was out in Chicago, we talked about
> shifting a bunch of the auth code out into "libsvn_auth". The specific
> clients for this library would be RA (performing interactions between the
> "server" and the auth information) and the user client (e.g. clients/cmdline
> for setting up the auth info). An opaque object would be passed into
> libsvn_client for later use by the underlying RA layer.
>
> The rationale for yanking it out into a separate library is that, right now,
> we have auth info kind of associated with RA (the various vtables), and also
> a bunch of stuff in CLIENT and clients/cmdline, also very specific. But as
> we add more auth types (think GUI clients, and certs), it is going to have a
> wide impact.
>
> I'm hoping that we can shove most of the auth-related stuff down into
> libsvn_auth to help encapsulate it a bit more, provide some nicer APIs, and
> to localize future auth work and bug fixes.
>
> Any thoughts? Objections? etc
+1 on splitting it out.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org