You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kevin Pilch-Bisson <ke...@pilch-bisson.net> on 2001/08/23 19:59:03 UTC
Auth in ra_dav
So today was the first time I have built/run subversion in a little while, and
I went to do a couple of things, and found that I can't do anything vi dav,
because I don't know how to authenticate myself. What do I have to do to make
subversion let me do stuff to the repository.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Auth in ra_dav
Posted by kf...@collab.net.
See also issue #456, folks, if you're thinking about auth issues.
-K
Greg Stein <gs...@lyra.org> writes:
> On Thu, Aug 23, 2001 at 03:59:03PM -0400, Kevin Pilch-Bisson wrote:
> > So today was the first time I have built/run subversion in a little while, and
> > I went to do a couple of things, and found that I can't do anything vi dav,
> > because I don't know how to authenticate myself. What do I have to do to make
> > subversion let me do stuff to the repository.
>
> The general story is this:
>
> ra_dav asks for username/password. Those are cached into the SVN directory.
> *If* the server asks for authentication, then we provide those.
>
> IOW, if you have not set up your server to require authentication, then you
> could enter anything you want for the user/pass since nobody will ever ask
> for them, nor check them against anything.
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 23, 2001 at 03:59:03PM -0400, Kevin Pilch-Bisson wrote:
> So today was the first time I have built/run subversion in a little while, and
> I went to do a couple of things, and found that I can't do anything vi dav,
> because I don't know how to authenticate myself. What do I have to do to make
> subversion let me do stuff to the repository.
The general story is this:
ra_dav asks for username/password. Those are cached into the SVN directory.
*If* the server asks for authentication, then we provide those.
IOW, if you have not set up your server to require authentication, then you
could enter anything you want for the user/pass since nobody will ever ask
for them, nor check them against anything.
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: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
You pop up in the funniest places, Logic... :-)
On Fri, Aug 24, 2001 at 04:19:38PM -0500, Edward S. Marshall wrote:
> On Fri, Aug 24, 2001 at 12:40:08PM -0700, Greg Stein wrote:
> > Nobody said anything about tunneling. We will definitely not do that. We
> > *have* a network protocol -- it is called HTTP. And that protocol can do
> > serious security (SSL/TLS, client certs, encryption, etc), commonly known as
> > "https".
>
> Besides, if you really want SSH tunnelling, you can do it invisibly with
> port forwarding; forward 127.0.0.1:80 to svnhost:80, configure svn to talk
> to localhost instead of svnhost, and set up access restrictions on svnhost
> to only allow connections FROM svnhost (either via Apache, or via host
> firewall rules).
>
> Simple, and no subversion modifications required. ;-)
>
> --
> Edward S. Marshall <es...@logic.net> http://esm.logic.net/
> -------------------------------------------------------------------------------
> [ Felix qui potuit rerum cognoscere causas. ]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
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: Auth in ra_dav
Posted by "Edward S. Marshall" <es...@logic.net>.
On Fri, Aug 24, 2001 at 12:40:08PM -0700, Greg Stein wrote:
> Nobody said anything about tunneling. We will definitely not do that. We
> *have* a network protocol -- it is called HTTP. And that protocol can do
> serious security (SSL/TLS, client certs, encryption, etc), commonly known as
> "https".
Besides, if you really want SSH tunnelling, you can do it invisibly with
port forwarding; forward 127.0.0.1:80 to svnhost:80, configure svn to talk
to localhost instead of svnhost, and set up access restrictions on svnhost
to only allow connections FROM svnhost (either via Apache, or via host
firewall rules).
Simple, and no subversion modifications required. ;-)
--
Edward S. Marshall <es...@logic.net> http://esm.logic.net/
-------------------------------------------------------------------------------
[ Felix qui potuit rerum cognoscere causas. ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 01:40:25PM +0200, Sander Striker wrote:
>...
> >> In the mean time, I'll see what I can find out about possibly writing
> >> a mod_auth_ssh / lib_ssh for per user 'tunnels'. This might have
> >> a wider application than subversion, come to think of it.
> >
> > Eh? Apache 2.0's mod_ssl already handles client certs, if I understand
> > things correctly.
Erp. Excuse me... I just realized you typed "ssh" rather than "ssl".
But ssh isn't what we want at all...
>...
> Imagine a community site moving over from ssh/cvs to subversion. It would
> be very nice if we could 'recycle' the users public keys (which were already
> present on the cvs machine) in subversion.
Agreed.
> What would be needed for that is
> probably a mod_ssh in apache and a ssh client lib to make life easier.
> Right now with ssh there are two ways to do tunneling:
Nobody said anything about tunneling. We will definitely not do that. We
*have* a network protocol -- it is called HTTP. And that protocol can do
serious security (SSL/TLS, client certs, encryption, etc), commonly known as
"https".
We'll use SSL and client certs. SSH tunneling is rather bogus when you
realize that HTTP over SSL and SSH are generally using the same technique --
why tunnel when our basic network can be secure?
>...
> But... I'll go bother some people first about ssl and ssh to get a bit
> better informed.
Good thinking :-)
Truly, the issue that we'd want to think about is how people can use their
ssh identities for SVN, and whether that is a good idea. (IMO, using a
different key pair for SVN is not a big deal, and could even be a Good Thing)
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: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> On Fri, Aug 24, 2001 at 01:39:00AM +0200, Sander Striker wrote:
>>> On Thu, Aug 23, 2001 at 10:39:54PM +0200, Sander Striker wrote:
>>>> Hi,
>>>>
>>>> Is it going to be possible to write a different authentication
>>>> mechanism than something that requires a username/password?
>>>> I'm talking about a plugin that might take a username/ssh private
>>>> key file. Ofcourse this should _not_ be stored in the wc. I
>>>> would be willing to invest some time in writing this if I get
>>>> a bit of guidance :)
>>>
>>> Other people have address this.
>>
>> Sorry, I'll go through the archives...
>
> Not in the archives -- this current thread. Specifically: we have two auth
> styles right now, it is extensible, etc etc.
>
>>...
>>> The exact mechanics are unknown. We'll work with Joe and Neon to
>>> see what we can do, and come up with something Good.
>>
>> There is no doubt in my mind about that.
>>
>> In the mean time, I'll see what I can find out about possibly writing
>> a mod_auth_ssh / lib_ssh for per user 'tunnels'. This might have
>> a wider application than subversion, come to think of it.
>
> Eh? Apache 2.0's mod_ssl already handles client certs, if I understand
> things correctly.
>
> [ just reviewed the code... sure looks like it. ]
Yes, I believe it does. But that is not really my point. Or maybe I just
still don't know enough about ssl and friends.
> So I'm not sure what you're thinking about doing. Maybe it is
> already done!
> (which doesn't suck...)
Ok, I'll try and write up what I'm thinking about.
[As a side comment: something similar may well be around. Currently there
are so many projects that I find it hard to find the ones that have my
true interest (bigger projects aside). Kind of like 'the best place to
hide a tree is a forest'.]
Here goes:
Imagine a community site moving over from ssh/cvs to subversion. It would
be very nice if we could 'recycle' the users public keys (which were already
present on the cvs machine) in subversion. What would be needed for that is
probably a mod_ssh in apache and a ssh client lib to make life easier.
Right now with ssh there are two ways to do tunneling:
- connect as a user to the machine and install an ssh forwarder;
- write your own protocol and start up the 'server' on the remote end using
the ssh.
The latter is what cvs has done. This would mean implementing an
alternative
protocol to dav/dav_svn and I don't think that would be a path to take.
The first I don't really consider an option, because IMHO you open up a can
of
worms when you allow user forwarding. And, since in subversion, users don't
have to
have an actual account, I'm inclined to take the direction of not giving
them one.
[in cvs users need a real account on the machine for unix permissions and
the
sshd authentication]
The alternative is implementing the authentication and encryption of ssh in
a
module, hence mod_ssh (the name is somewhat misleading, unless it could also
do what ssh does now, configurable with options in httpd.conf, but I'm
drifting...).
mod_ssh should simply wait for connections, authenticate the user, and then
serve as an encrypted tunnel. The ssh channel mechanism looks like a
candidate
for this. I must admit that I have always had a weakness for ssh, so that's
probably why I want to do something with it. Implementing it in a mod,
using
apr seems like a nice exercise.
But... I'll go bother some people first about ssl and ssh to get a bit
better
informed. Sorry to have caused another 'interrupt to be raised' snatching
precious time away from M3.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 01:39:00AM +0200, Sander Striker wrote:
> > On Thu, Aug 23, 2001 at 10:39:54PM +0200, Sander Striker wrote:
> > > Hi,
> > >
> > > Is it going to be possible to write a different authentication
> > > mechanism than something that requires a username/password?
> > > I'm talking about a plugin that might take a username/ssh private
> > > key file. Ofcourse this should _not_ be stored in the wc. I
> > > would be willing to invest some time in writing this if I get
> > > a bit of guidance :)
> >
> > Other people have address this.
>
> Sorry, I'll go through the archives...
Not in the archives -- this current thread. Specifically: we have two auth
styles right now, it is extensible, etc etc.
>...
> > The exact mechanics are unknown. We'll work with Joe and Neon to
> > see what we can do, and come up with something Good.
>
> There is no doubt in my mind about that.
>
> In the mean time, I'll see what I can find out about possibly writing
> a mod_auth_ssh / lib_ssh for per user 'tunnels'. This might have
> a wider application than subversion, come to think of it.
Eh? Apache 2.0's mod_ssl already handles client certs, if I understand
things correctly.
[ just reviewed the code... sure looks like it. ]
So I'm not sure what you're thinking about doing. Maybe it is already done!
(which doesn't suck...)
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: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> On Thu, Aug 23, 2001 at 10:39:54PM +0200, Sander Striker wrote:
> > Hi,
> >
> > Is it going to be possible to write a different authentication
> > mechanism than something that requires a username/password?
> > I'm talking about a plugin that might take a username/ssh private
> > key file. Ofcourse this should _not_ be stored in the wc. I
> > would be willing to invest some time in writing this if I get
> > a bit of guidance :)
>
> Other people have address this.
Sorry, I'll go through the archives...
> > But probably this is not something for 1.0...
>
> We *will* be doing client certificates for 1.0. That will put us
> on par with CVS and ssh tunneling.
Ah, good to know that the certificates are going to be in.
> The exact mechanics are unknown. We'll work with Joe and Neon to
> see what we can do, and come up with something Good.
There is no doubt in my mind about that.
In the mean time, I'll see what I can find out about possibly writing
a mod_auth_ssh / lib_ssh for per user 'tunnels'. This might have
a wider application than subversion, come to think of it.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 23, 2001 at 10:39:54PM +0200, Sander Striker wrote:
> Hi,
>
> Is it going to be possible to write a different authentication
> mechanism than something that requires a username/password?
> I'm talking about a plugin that might take a username/ssh private
> key file. Ofcourse this should _not_ be stored in the wc. I
> would be willing to invest some time in writing this if I get
> a bit of guidance :)
Other people have address this.
> But probably this is not something for 1.0...
We *will* be doing client certificates for 1.0. That will put us on par with
CVS and ssh tunneling.
The exact mechanics are unknown. We'll work with Joe and Neon to see what we
can do, and come up with something Good.
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: Auth in ra_dav
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Thu, Aug 23, 2001 at 10:39:54PM +0200, Sander Striker wrote:
> Hi,
>
> Is it going to be possible to write a different authentication
> mechanism than something that requires a username/password?
> I'm talking about a plugin that might take a username/ssh private
> key file. Ofcourse this should _not_ be stored in the wc. I
> would be willing to invest some time in writing this if I get
> a bit of guidance :)
neon supports SSL client certs, so some of the work is done. Of course
to be any where near as slick as a cvs/ssh/ssh-agent combination,
there's a tonne of work to do.
But getting basic client cert support in shouldn't be too hard to add to
ra_dav.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] Re: svn auth
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 04:08:33PM -0400, C. Scott Ananian wrote:
> On Fri, 24 Aug 2001, Greg Stein wrote:
>
> > I think you should learn more about the existing Apache authentication and
> > determine where/how that fails what you have in mind. It would /not/ be good
> > for SVN to go and develop a complete, secondary auth system when the front
> > line of our server is Apache. Integrating the auth system tightly with
> > Apache will be the best thing for admins out there. Maintaining multiple
> > auth systems is one of the bigger problems for an admin.
>
> But what about local repositories? Surely *some* secondary auth system is
> required.
Nope. If you have write access to the Berkeley DB (as you must for a local
repository), then you can circumvent any authorization system. Therefore, we
aren't even going to try to put one in place -- it would give people a false
sense of security.
(note: in the local case, authentication is already done: your login; it is
*authorization* that we're talking about at that point... this thread is
wavering back and forth between authentication and authorization...)
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-DEV] Re: svn auth
Posted by "C. Scott Ananian" <ca...@lesser-magoo.lcs.mit.edu>.
On Fri, 24 Aug 2001, Greg Stein wrote:
> I think you should learn more about the existing Apache authentication and
> determine where/how that fails what you have in mind. It would /not/ be good
> for SVN to go and develop a complete, secondary auth system when the front
> line of our server is Apache. Integrating the auth system tightly with
> Apache will be the best thing for admins out there. Maintaining multiple
> auth systems is one of the bigger problems for an admin.
But what about local repositories? Surely *some* secondary auth system is
required.
--s
smuggle pending immediate COBRA JANE affinity group security Chechnya
operative interception shortwave cryptographic atomic SDI Soviet
( http://lesser-magoo.lcs.mit.edu/~cananian )
--
"These students are going to have to find out what law and order is
all about." -- Brig. General Robert Canterbury, Noon, May 4, 1970,
minutes before his troops shot 13 unarmed Kent State students, killing 4.
--
[http://www.cs.cmu.edu/~dst/DeCSS/Gallery/]
#!/usr/bin/perl -w
# 526-byte qrpff, Keith Winstein and Marc Horowitz <si...@mit.edu>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn auth
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 05:40:09PM +0200, Sander Striker wrote:
>...
> 1. Will the action specific access control be maintained (as
> currently described in the design doc)?
We can easily limit on a per-HTTP method basis. For example, we require an
authenticated, valid user for the MKACTIVITY, CHECKOUT, and PUT methods.
Without those, a person cannot commit a change.
Of course... that isn't wrapped up as "nice" SVN concepts, which is where a
mod_auth_svn might come into play.
> This is a very usefull feature, to say the least. I'm referring
> to the example idea of a back-end implementation of svn_authorize().
> There roles are mapped to users and repository paths.
I think you should learn more about the existing Apache authentication and
determine where/how that fails what you have in mind. It would /not/ be good
for SVN to go and develop a complete, secondary auth system when the front
line of our server is Apache. Integrating the auth system tightly with
Apache will be the best thing for admins out there. Maintaining multiple
auth systems is one of the bigger problems for an admin.
CVS is just such a beast with its separate CVSROOT/passwd crap. Through
Apache's authentication hooks, we can integrate with an admin's PAM
database, or an LDAP server of users, or Kerberos or NTLM or whatever.
>...
> I understand that the svn_security file idea is outdated, but
> something anologue to that would surely be implemented(?), keeping
> these points valid.
I don't recall the design of the svn_security file, nor will I research. It
is dead and gone. :-) Again, I'd recommend learning the current system and
bringing up your ideas w.r.t to that.
> 2. Are the supported auth methods going to be configurable (ie. can
> an admin switch the weaker ones off?
Absolutely. Apache allows you to state what auth methods are acceptable for
a given location in the tree.
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-DEV] RE: Auth in ra_dav
Posted by kf...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> While true... we have a long time to worry about that. In the meantime,
> having to deal with sentinels can be a distraction from what is needed for
> 1.0. When different backends arrive, then we can examine other mechanisms
> for authorization (which may include introducing a sentinels-like system).
>
> > Then again, discussion is always ok :)
>
> IMO, not always. It can be awfully distracting sometimes. Personally, I'd
> rather spend time on 1.0 than discussing post-1.0 items.
True, but in this particular case, I think the discussion is very
helpful. Designing authorization systems is an area where experience
counts even more than usual. This list has a lot of such experience,
collectively, and Subversion should take advantage of it.
For example, there might be something better than the sentinel system
we've planning right now. I've always had the feeling that we might
be reinventing a wheel there; if someone on this list recognizes the
wheel and knows a better way to do it, that would be great. The
chance of that benefit makes the "burden" of discussion a good risk,
IMHO.
> OTOH, I don't approve of censoring or hard rules about mailing list content.
> So that puts me in a quandary :-)
Enjoy; let us know if you need pizza shipped in or anything! :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] RE: Auth in ra_dav
Posted by Tripp Lilley <tl...@perspex.com>.
On Fri, 24 Aug 2001, Greg Stein wrote:
> While true... we have a long time to worry about that. In the meantime,
> having to deal with sentinels can be a distraction from what is needed for
> 1.0. When different backends arrive, then we can examine other mechanisms
> for authorization (which may include introducing a sentinels-like system).
Don't forget that there's also the tabled discussion of whether or not
there should even *be* a "local-only" mechanism, or whether someone would
make a nice, trivial, very buttoned up Apache package to ship as part of a
"local-only" binary / source distro.
Assuming that happened, "local-only" AAA would no longer be a special
case.
--
Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/
--------------------------------------------------------------------------
"The human soul is the greatest anti-piracy measure in the known
world, but no major company will use it."
<http://slashdot.org/comments.pl?sid=01/07/19/007240&cid=94>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [SVN-DEV] RE: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> On Sat, Aug 25, 2001 at 12:37:41AM +0200, Sander Striker wrote:
>>...
>> The case where apache isn't involved. We need a way to let the repos
>> handle if a user X is allowed Y on path Z. The berkeley argument won't
>> hold, since if we get around to implementing the sql backend, writing
>> to the repos isn't so easy as it is now with berkeley db. This can
>> be done through hooks. The read/write sentinels seems a pretty
>> efficient solution.
>
> While true... we have a long time to worry about that. In the meantime,
> having to deal with sentinels can be a distraction from what is needed for
> 1.0. When different backends arrive, then we can examine other mechanisms
> for authorization (which may include introducing a sentinels-like system).
>
>> Then again, discussion is always ok :)
>
> IMO, not always. It can be awfully distracting sometimes. Personally, I'd
> rather spend time on 1.0 than discussing post-1.0 items.
'Always' was a bit of a poorly choosen word. I should have left it out.
What I meant was that discussion about a different solution for the authz
problem would probably be a good thing, once the time is there to implement
it. For now, lets please get to M3 first :) [I'll try to shut up for a
little while now].
> OTOH, I don't approve of censoring or hard rules about mailing
> list content.
> So that puts me in a quandary :-)
:)
> Cheers,
> -g
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] RE: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Aug 25, 2001 at 12:37:41AM +0200, Sander Striker wrote:
>...
> The case where apache isn't involved. We need a way to let the repos
> handle if a user X is allowed Y on path Z. The berkeley argument won't
> hold, since if we get around to implementing the sql backend, writing
> to the repos isn't so easy as it is now with berkeley db. This can
> be done through hooks. The read/write sentinels seems a pretty efficient
> solution.
While true... we have a long time to worry about that. In the meantime,
having to deal with sentinels can be a distraction from what is needed for
1.0. When different backends arrive, then we can examine other mechanisms
for authorization (which may include introducing a sentinels-like system).
> Then again, discussion is always ok :)
IMO, not always. It can be awfully distracting sometimes. Personally, I'd
rather spend time on 1.0 than discussing post-1.0 items.
OTOH, I don't approve of censoring or hard rules about mailing list content.
So that puts me in a quandary :-)
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 and Authorization
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Aug 25, 2001 at 06:48:46PM -0700, Josh Siegel wrote:
>...
> Obviously some pam-like authentication modules for LDAP/AD will have to be
> written...Currently, my version of CVS can be set to execute a external
> shell script for authentication. We use a smbclient to authenticate windows
> users but plan on switching over to LDAP once we've upgraded the core
> servers to Windows 2000
>
> Of course, we use the same authentication scripts for our apache server...
For the Apache side, you could use mod_ntlm today:
http://modntlm.sourceforge.net/
When you upgrade your servers, you could switch to mod_auth_ldap. (note that
the latter is already incorporated into the Apache 2.0 CVS, although it will
probably move from the std. distro to an ASF "rollup" distro)
One of the reasons that we chose Apache for our network server is its
flexibility in authentication systems. There was no way that we (the SVN
team) wanted to do a bunch of work for each possible authentication
mechanism out there (or come up with our own(?!!)).
Cheers,
-g
p.s. okay... so I needed to convince the other guys about using Apache to
avoid the auth situation, but it didn't take too long to show them the
Light... :-)
--
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 and Authorization
Posted by Josh Siegel <jo...@stormbirds.org>.
[...]
How do you -identify- somebody (and hence their privileges) in a
cross-platform way? Digital IDs/LDAP spring to mind, but I guess this is
complex.
[...]
Obviously some pam-like authentication modules for LDAP/AD will have to be
written...Currently, my version of CVS can be set to execute a external
shell script for authentication. We use a smbclient to authenticate windows
users but plan on switching over to LDAP once we've upgraded the core
servers to Windows 2000
Of course, we use the same authentication scripts for our apache server...
-josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN and Authorization
Posted by roger day <ro...@nenuphar.freeserve.co.uk>.
How do you -identify- somebody (and hence their privileges) in a cross-platform way? Digital IDs/LDAP spring to mind, but I guess this is complex.
----- Original Message -----
From: "Bill Tutt" <ra...@lyra.org>
To: "'C. Scott Ananian'" <ca...@lesser-magoo.lcs.mit.edu>
Cc: <de...@subversion.tigris.org>
Sent: Saturday, August 25, 2001 02:32
Subject: SVN and Authorization
>
>
> From: C. Scott Ananian [mailto:cananian@lesser-magoo.lcs.mit.edu]:
>
> > On Sat, 25 Aug 2001, Sander Striker wrote:
>
> > > The case where apache isn't involved. We need a way to let the
> repos
> > > handle if a user X is allowed Y on path Z. The berkeley argument
> > > won't hold, since if we get around to implementing the sql backend,
> > > writing to the repos isn't so easy as it is now with berkeley db.
> > > This can be done through hooks. The read/write sentinels seems a
> > > pretty efficient solution. Then again, discussion is always ok :)
>
> > I read the berkeley db argument as, "The filesystem is responsible for
> > authentication and enforcing access controls for local repositories".
> > The initial file system implementation, built on Berkeley DB, seems to
> > be a 'permissions-free' file system. As you point out, implementing
> > the filesystem on top of a "real" DB would enforce whatever
> > authentication/access control mechanisms the DB enforced. I'm still
> > hoping for a plain-text unixy filesystem implementation at some point;
> > this impl would extends unix authentication/etc to SVN.
>
> Ick. You really don't want to use a unixy file system approach to
> authorization issues.
> Security models have gotten so much better since then.
>
> Here's a possible security model for SVN:
>
> There are the following access levels:
> * Read: The level ViewSVN would need. Displays file histories, and
> actual contents, but you can't actually commit any changes.
> * Write: You can commit changes, and stuff.
> * Admin: You can do anything. (user management, etc...)
>
> An SVN ACL would contain the following info:
> * Access level
> * User/Group this Access Level applies to, can apply to everyone (except
> admin).
> * Hosts this access level is allowed for. (Standard IP wildcarding stuff
> here)
> * Path of the repository that this access applies to. E.g. a path of '/'
> would mean apply to the whole repository. While a path of '/blah/blah2'
> would apply to all subdirectories of blah2.
>
> A DACL (deny ACL) would contain the exact same information, except it
> would prevent the associated user/group from obtaining the requested
> access level on a given path.
>
> Decent security models allow resources to be accessed by more than one
> group, and allow the use of DACLs to handle group overlap problem cases.
> Unix filesystems don't even come close to allowing that kind of
> flexibility.
>
> Note: The above doesn't take any kind of consideration for the current
> state of the SVN file system layer, it's just an idea. :)
>
> Bill
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
SVN and Authorization
Posted by Bill Tutt <ra...@lyra.org>.
From: C. Scott Ananian [mailto:cananian@lesser-magoo.lcs.mit.edu]:
> On Sat, 25 Aug 2001, Sander Striker wrote:
> > The case where apache isn't involved. We need a way to let the
repos
> > handle if a user X is allowed Y on path Z. The berkeley argument
> > won't hold, since if we get around to implementing the sql backend,
> > writing to the repos isn't so easy as it is now with berkeley db.
> > This can be done through hooks. The read/write sentinels seems a
> > pretty efficient solution. Then again, discussion is always ok :)
> I read the berkeley db argument as, "The filesystem is responsible for
> authentication and enforcing access controls for local repositories".
> The initial file system implementation, built on Berkeley DB, seems to
> be a 'permissions-free' file system. As you point out, implementing
> the filesystem on top of a "real" DB would enforce whatever
> authentication/access control mechanisms the DB enforced. I'm still
> hoping for a plain-text unixy filesystem implementation at some point;
> this impl would extends unix authentication/etc to SVN.
Ick. You really don't want to use a unixy file system approach to
authorization issues.
Security models have gotten so much better since then.
Here's a possible security model for SVN:
There are the following access levels:
* Read: The level ViewSVN would need. Displays file histories, and
actual contents, but you can't actually commit any changes.
* Write: You can commit changes, and stuff.
* Admin: You can do anything. (user management, etc...)
An SVN ACL would contain the following info:
* Access level
* User/Group this Access Level applies to, can apply to everyone (except
admin).
* Hosts this access level is allowed for. (Standard IP wildcarding stuff
here)
* Path of the repository that this access applies to. E.g. a path of '/'
would mean apply to the whole repository. While a path of '/blah/blah2'
would apply to all subdirectories of blah2.
A DACL (deny ACL) would contain the exact same information, except it
would prevent the associated user/group from obtaining the requested
access level on a given path.
Decent security models allow resources to be accessed by more than one
group, and allow the use of DACLs to handle group overlap problem cases.
Unix filesystems don't even come close to allowing that kind of
flexibility.
Note: The above doesn't take any kind of consideration for the current
state of the SVN file system layer, it's just an idea. :)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [SVN-DEV] RE: Auth in ra_dav
Posted by "C. Scott Ananian" <ca...@lesser-magoo.lcs.mit.edu>.
On Sat, 25 Aug 2001, Sander Striker wrote:
> The case where apache isn't involved. We need a way to let the repos
> handle if a user X is allowed Y on path Z. The berkeley argument won't
> hold, since if we get around to implementing the sql backend, writing
> to the repos isn't so easy as it is now with berkeley db. This can
> be done through hooks. The read/write sentinels seems a pretty efficient
> solution. Then again, discussion is always ok :)
I read the berkeley db argument as, "The filesystem is responsible for
authentication and enforcing access controls for local repositories". The
initial file system implementation, built on Berkeley DB, seems to be a
'permissions-free' file system. As you point out, implementing the
filesystem on top of a "real" DB would enforce whatever
authentication/access control mechanisms the DB enforced. I'm still
hoping for a plain-text unixy filesystem implementation at some point;
this impl would extends unix authentication/etc to SVN.
I just hope that SVN's filesystem interface includes an errno for
'permission denied' and that SVN will do a sensible thing if/when this
error is encountered.
--s
Minister AP shortwave Hawk affinity group Milosevic interception UKUSA
Morwenstow cryptographic Richard Tomlinson Waihopai LA FSF assassination
( http://lesser-magoo.lcs.mit.edu/~cananian )
--
"These students are going to have to find out what law and order is
all about." -- Brig. General Robert Canterbury, Noon, May 4, 1970,
minutes before his troops shot 13 unarmed Kent State students, killing 4.
--
[http://www.cs.cmu.edu/~dst/DeCSS/Gallery/]
#!/usr/bin/perl -w
# 526-byte qrpff, Keith Winstein and Marc Horowitz <si...@mit.edu>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [SVN-DEV] RE: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> On Fri, Aug 24, 2001 at 10:58:04PM +0200, Sander Striker wrote:
> >...
> > Yes, that was something on my mind too :)
> > I'll speak to Ben Laurie again and see if he can explain the details
> > of the certificate generation process to me. I'll then get started
> > on such a conversion util (which we could dump in /contrib ?)
> provided it
> > is at all possible. In any case I'll report back here.
>
> I would hope that you would contribute it to the Subversion project, and
> we'd check it into the tools directory.
>
> > Greg gave a good insight on the authentication part of my
> question(s), thx.
> > As for the authorization part, that's going to work through hooks which
> > is a 'Good Thing' because it is easily custimizable. Once the protocol
> > is set for the r/w sentinels (or once you get discussing these)
> > I'll jump in again ;)
>
> Apache does both authentication and authorization. I'm still waiting for
> people to explain what kinds of authz they want that Apache can't
> handle.
The case where apache isn't involved. We need a way to let the repos
handle if a user X is allowed Y on path Z. The berkeley argument won't
hold, since if we get around to implementing the sql backend, writing
to the repos isn't so easy as it is now with berkeley db. This can
be done through hooks. The read/write sentinels seems a pretty efficient
solution. Then again, discussion is always ok :)
> Or for a specific design that they'd like to see, which we could then use
> within the standard Apache authz system.
:)
> [ as you may have guessed, I'm not a fan of external authz systems. and I
> think that I may even disagree with the sentinel concept (need more
> research and thinking on that) (it seems they just kind of
> appeared while I was away; either that, or whothehellknows where I
> was :-)) ]
That tends to happen :)
> 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-DEV] RE: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 10:58:04PM +0200, Sander Striker wrote:
>...
> Yes, that was something on my mind too :)
> I'll speak to Ben Laurie again and see if he can explain the details
> of the certificate generation process to me. I'll then get started
> on such a conversion util (which we could dump in /contrib ?) provided it
> is at all possible. In any case I'll report back here.
I would hope that you would contribute it to the Subversion project, and
we'd check it into the tools directory.
> Greg gave a good insight on the authentication part of my question(s), thx.
> As for the authorization part, that's going to work through hooks which
> is a 'Good Thing' because it is easily custimizable. Once the protocol
> is set for the r/w sentinels (or once you get discussing these) I'll jump
> in again ;)
Apache does both authentication and authorization. I'm still waiting for
people to explain what kinds of authz they want that Apache can't handle. Or
for a specific design that they'd like to see, which we could then use
within the standard Apache authz system.
[ as you may have guessed, I'm not a fan of external authz systems. and I
think that I may even disagree with the sentinel concept (need more
research and thinking on that) (it seems they just kind of appeared while
I was away; either that, or whothehellknows where I was :-)) ]
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-DEV] RE: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> On Fri, Aug 24, 2001 at 03:57:25PM -0400, C. Scott Ananian wrote:
> > On Fri, 24 Aug 2001, Sander Striker wrote:
> > > And, I've been having a little chat with Ben Laurie that is probably
> > > bringing me back to reallity: client certs.
> > >
> > > I guess I will just have to forget about ssh in combination
> with svn :)
> >
> > SSH and client certificates both use public-key cryptography, and (I
> > believe) the actual algorithms to use are selectable in the protocol.
> > Why don't you see if you can write a ssh-public-key to "public"
> > client-cert and ssh-private-key to "private" client-cert converter, with
> > the aim of making it as easy as possibly to do the migration
> (i.e. without
> > requiring another key exchange with the project host)?
>
> Ah. Good idea... that is just the kind of idea I was hoping people would
> come up with.
Yes, that was something on my mind too :)
I'll speak to Ben Laurie again and see if he can explain the details
of the certificate generation process to me. I'll then get started
on such a conversion util (which we could dump in /contrib ?) provided it
is at all possible. In any case I'll report back here.
Greg gave a good insight on the authentication part of my question(s), thx.
As for the authorization part, that's going to work through hooks which
is a 'Good Thing' because it is easily custimizable. Once the protocol
is set for the r/w sentinels (or once you get discussing these) I'll jump
in again ;)
Sander
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [SVN-DEV] RE: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 03:57:25PM -0400, C. Scott Ananian wrote:
> On Fri, 24 Aug 2001, Sander Striker wrote:
> > And, I've been having a little chat with Ben Laurie that is probably
> > bringing me back to reallity: client certs.
> >
> > I guess I will just have to forget about ssh in combination with svn :)
>
> SSH and client certificates both use public-key cryptography, and (I
> believe) the actual algorithms to use are selectable in the protocol.
> Why don't you see if you can write a ssh-public-key to "public"
> client-cert and ssh-private-key to "private" client-cert converter, with
> the aim of making it as easy as possibly to do the migration (i.e. without
> requiring another key exchange with the project host)?
Ah. Good idea... that is just the kind of idea I was hoping people would
come up with.
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-DEV] RE: Auth in ra_dav
Posted by "C. Scott Ananian" <ca...@lesser-magoo.lcs.mit.edu>.
On Fri, 24 Aug 2001, Sander Striker wrote:
> And, I've been having a little chat with Ben Laurie that is probably
> bringing me back to reallity: client certs.
>
> I guess I will just have to forget about ssh in combination with svn :)
SSH and client certificates both use public-key cryptography, and (I
believe) the actual algorithms to use are selectable in the protocol.
Why don't you see if you can write a ssh-public-key to "public"
client-cert and ssh-private-key to "private" client-cert converter, with
the aim of making it as easy as possibly to do the migration (i.e. without
requiring another key exchange with the project host)?
--s
Milosevic RUCKUS cryptographic SDI Saddam Hussein pending Suharto
Mk 48 Yakima blowfish Richard Tomlinson Mossad NRA DC AES Dictionary
( http://lesser-magoo.lcs.mit.edu/~cananian )
--
"These students are going to have to find out what law and order is
all about." -- Brig. General Robert Canterbury, Noon, May 4, 1970,
minutes before his troops shot 13 unarmed Kent State students, killing 4.
--
[http://www.cs.cmu.edu/~dst/DeCSS/Gallery/]
#!/usr/bin/perl -w
# 526-byte qrpff, Keith Winstein and Marc Horowitz <si...@mit.edu>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn auth, WAS: RE: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 12:41:22PM -0500, Ben Collins-Sussman wrote:
> "Sander Striker" <st...@apache.org> writes:
>
> > > [...]
> > > >> If you want to understand our PAM-like authentication, look at:
> > > >>
> > > >> * subversion/include/svn_ra.h
> > > >> * subversion/libsvn_client/auth.c
> > > >> * issue #456, for future plans.
> >
> > Hmmm, maybe subversion/svn_repos/hooks.txt is a good one to add to
> > this list too. The read/write sentinels eliminate all comments
> > below...
>
> Exactly.
>
> If you want fancy roles and custom authorization rules, write it, and
> talk to it via hook scripts. :-)
>
> Otherwise, svn 1.0 will probably use simple authorization built into
> Apache.
I wouldn't exactly call it "simple" :-)
It can do a lot of different things, but I think the issue is more along the
lines of "can it do it precisely <this> way?" And when that comes up, we can
use a custom Apache module (best), or we can use hooks in various ways.
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 auth, WAS: RE: Auth in ra_dav
Posted by Ben Collins-Sussman <su...@collab.net>.
"Sander Striker" <st...@apache.org> writes:
> > [...]
> > >> If you want to understand our PAM-like authentication, look at:
> > >>
> > >> * subversion/include/svn_ra.h
> > >> * subversion/libsvn_client/auth.c
> > >> * issue #456, for future plans.
>
> Hmmm, maybe subversion/svn_repos/hooks.txt is a good one to add to
> this list too. The read/write sentinels eliminate all comments
> below...
Exactly.
If you want fancy roles and custom authorization rules, write it, and
talk to it via hook scripts. :-)
Otherwise, svn 1.0 will probably use simple authorization built into
Apache.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn auth, WAS: RE: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> [...]
> >> If you want to understand our PAM-like authentication, look at:
> >>
> >> * subversion/include/svn_ra.h
> >> * subversion/libsvn_client/auth.c
> >> * issue #456, for future plans.
Hmmm, maybe subversion/svn_repos/hooks.txt is a good one to add to
this list too. The read/write sentinels eliminate all comments
below...
Sander
> Ok, comments and stuff to think about:
>
> 1. Will the action specific access control be maintained (as
> currently described in the design doc)?
>
> This is a very usefull feature, to say the least. I'm referring
> to the example idea of a back-end implementation of svn_authorize().
> There roles are mapped to users and repository paths.
>
> To extend this idea it would be nice that if all authentication
> fails, the username is set to 'anonymous', which can then be used
> to allow for adding rules like:
>
> anonymous : visitor /trunk/project
>
> I would also like to be able to specify a rule that would be used
> when other rules fail to work because the repository path isn't
> explicitly mentioned in the rule:
>
> all : visitor /trunk/project
>
> When having a config like so:
>
> striker : hacker /trunk/project/subdir
> x : offlimits /trunk/project2
> anonymous : visitor /trunk/project : visitor /trunk/project2
> all : visitor /trunk/project : visitor /trunk/project2
>
> This would save specifying for user striker that he has 'visitor'
> rights to all the projects not in his rule. This comes into
> view once a new developer gets commit access to a single project
> in the repository, but all other projects are public. IMHO it
> should be possible to do an 'authenticated' checkout for projects
> that can be checked out anonymously.
> Oh, in this particular example a checkout of /trunk/project2 by
> user x would fail, because there is a specification of what should
> be done.
>
> I understand that the svn_security file idea is outdated, but
> something anologue to that would surely be implemented(?), keeping
> these points valid.
>
> 2. Are the supported auth methods going to be configurable (ie. can
> an admin switch the weaker ones off?
>
> 3. ...
>
> Damn I had more stuff, but seem to have forgotten what I wanted
> to say :( Maybe more later (or tell me to please shut up :).
>
>
> Sander
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
svn auth, WAS: RE: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
[...]
>> If you want to understand our PAM-like authentication, look at:
>>
>> * subversion/include/svn_ra.h
>> * subversion/libsvn_client/auth.c
>> * issue #456, for future plans.
Ok, comments and stuff to think about:
1. Will the action specific access control be maintained (as
currently described in the design doc)?
This is a very usefull feature, to say the least. I'm referring
to the example idea of a back-end implementation of svn_authorize().
There roles are mapped to users and repository paths.
To extend this idea it would be nice that if all authentication
fails, the username is set to 'anonymous', which can then be used
to allow for adding rules like:
anonymous : visitor /trunk/project
I would also like to be able to specify a rule that would be used
when other rules fail to work because the repository path isn't
explicitly mentioned in the rule:
all : visitor /trunk/project
When having a config like so:
striker : hacker /trunk/project/subdir
x : offlimits /trunk/project2
anonymous : visitor /trunk/project : visitor /trunk/project2
all : visitor /trunk/project : visitor /trunk/project2
This would save specifying for user striker that he has 'visitor'
rights to all the projects not in his rule. This comes into
view once a new developer gets commit access to a single project
in the repository, but all other projects are public. IMHO it
should be possible to do an 'authenticated' checkout for projects
that can be checked out anonymously.
Oh, in this particular example a checkout of /trunk/project2 by
user x would fail, because there is a specification of what should
be done.
I understand that the svn_security file idea is outdated, but
something anologue to that would surely be implemented(?), keeping
these points valid.
2. Are the supported auth methods going to be configurable (ie. can
an admin switch the weaker ones off?
3. ...
Damn I had more stuff, but seem to have forgotten what I wanted
to say :( Maybe more later (or tell me to please shut up :).
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> kfogel@collab.net writes:
>
> > "Sander Striker" <st...@apache.org> writes:
> > > > > What I would like to do is something like storing the
> public key in
> > > > > the repository access definitions file.
> > > >
> > > > Eh? Never heard of the "repository access definitions file".
> > >
> > > 'svn_security' in '7.2.1.2 Authorization' in the design doc.
> >
> > Oops. Time to update the design doc. :-)
> >
> > (Seriously, the auth section is one of the most out-of-date things in
> > there.)
>
> Yeah, we wrote that specification 15 months ago, and then "updated" it
> about 6 months ago, to reflect the actual design changes we had made.
> Authentication stuff just came into being in the last 2 months, so I'd
> better go in there and do some more purging/rewriting. Sorry to lead
> you astray. That document is about 80% accurate, at least. :-)
>
> If you want to understand our PAM-like authentication, look at:
>
> * subversion/include/svn_ra.h
> * subversion/libsvn_client/auth.c
> * issue #456, for future plans.
Thanks. I have now :)
And, I've been having a little chat with Ben Laurie that is probably
bringing me back to reallity: client certs.
I guess I will just have to forget about ssh in combination with svn :)
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auth in ra_dav
Posted by Ben Collins-Sussman <su...@collab.net>.
kfogel@collab.net writes:
> "Sander Striker" <st...@apache.org> writes:
> > > > What I would like to do is something like storing the public key in
> > > > the repository access definitions file.
> > >
> > > Eh? Never heard of the "repository access definitions file".
> >
> > 'svn_security' in '7.2.1.2 Authorization' in the design doc.
>
> Oops. Time to update the design doc. :-)
>
> (Seriously, the auth section is one of the most out-of-date things in
> there.)
Yeah, we wrote that specification 15 months ago, and then "updated" it
about 6 months ago, to reflect the actual design changes we had made.
Authentication stuff just came into being in the last 2 months, so I'd
better go in there and do some more purging/rewriting. Sorry to lead
you astray. That document is about 80% accurate, at least. :-)
If you want to understand our PAM-like authentication, look at:
* subversion/include/svn_ra.h
* subversion/libsvn_client/auth.c
* issue #456, for future plans.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auth in ra_dav
Posted by kf...@collab.net.
"Sander Striker" <st...@apache.org> writes:
> > > What I would like to do is something like storing the public key in
> > > the repository access definitions file.
> >
> > Eh? Never heard of the "repository access definitions file".
>
> 'svn_security' in '7.2.1.2 Authorization' in the design doc.
Oops. Time to update the design doc. :-)
(Seriously, the auth section is one of the most out-of-date things in
there.)
-K
> > >...
> > > But, like I said, this is probably something for after 1.0. I'm
> > > inclined to take a look at a sql fs backend first...
> >
> > It is for 1.0. A SQL backend is for 2.0. Note that we're already thinking
> > that a 1.1 release would add some more tools/enhancements and i18n.
> >
> > Cheers,
> > -g
>
> Sander
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> On Fri, Aug 24, 2001 at 12:08:09AM +0200, Sander Striker wrote:
> >...
> > > > Ofcourse this should _not_ be stored in the wc.
> > >
> > > Right now, all authentication info is saved in SVN/auth/, which is
> > > chmod'ed to 0700. Is that not safe enough for you? :-)
> >
> > Well, I only want _one_ copy of my private key :)
> > Or are we talking the private key filename? Hmm, ofcourse, that just
> > depends on how it is implemented.
>
> Dunno.
>
> > What I would like to do is something like storing the public key in
> > the repository access definitions file.
>
> Eh? Never heard of the "repository access definitions file".
'svn_security' in '7.2.1.2 Authorization' in the design doc.
> >...
> > But, like I said, this is probably something for after 1.0. I'm
> > inclined to take a look at a sql fs backend first...
>
> It is for 1.0. A SQL backend is for 2.0. Note that we're already thinking
> that a 1.1 release would add some more tools/enhancements and i18n.
>
> Cheers,
> -g
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auth in ra_dav
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 12:08:09AM +0200, Sander Striker wrote:
>...
> > > Ofcourse this should _not_ be stored in the wc.
> >
> > Right now, all authentication info is saved in SVN/auth/, which is
> > chmod'ed to 0700. Is that not safe enough for you? :-)
>
> Well, I only want _one_ copy of my private key :)
> Or are we talking the private key filename? Hmm, ofcourse, that just
> depends on how it is implemented.
Dunno.
> What I would like to do is something like storing the public key in
> the repository access definitions file.
Eh? Never heard of the "repository access definitions file".
>...
> But, like I said, this is probably something for after 1.0. I'm
> inclined to take a look at a sql fs backend first...
It is for 1.0. A SQL backend is for 2.0. Note that we're already thinking
that a 1.1 release would add some more tools/enhancements and i18n.
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: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
> > Hi,
> >
> > Is it going to be possible to write a different authentication
> > mechanism than something that requires a username/password?
> > I'm talking about a plugin that might take a username/ssh private
> > key file.
>
> Sure. libsvn_client and libsvn_ra have a "PAM"-like authentication
> architecture. Only two methods are defined: username only, and
> username/password. But you can write more of them. Look in svn_ra.h
> more more information.
>
> > Ofcourse this should _not_ be stored in the wc.
>
> Right now, all authentication info is saved in SVN/auth/, which is
> chmod'ed to 0700. Is that not safe enough for you? :-)
Well, I only want _one_ copy of my private key :)
Or are we talking the private key filename? Hmm, ofcourse, that just
depends on how it is implemented.
What I would like to do is something like storing the public key in
the repository access definitions file. Maybe as a 4th thing in
svn_security.
striker : <public key>
But, like I said, this is probably something for after 1.0. I'm
inclined to take a look at a sql fs backend first...
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auth in ra_dav
Posted by Ben Collins-Sussman <su...@collab.net>.
"Sander Striker" <st...@apache.org> writes:
> Hi,
>
> Is it going to be possible to write a different authentication
> mechanism than something that requires a username/password?
> I'm talking about a plugin that might take a username/ssh private
> key file.
Sure. libsvn_client and libsvn_ra have a "PAM"-like authentication
architecture. Only two methods are defined: username only, and
username/password. But you can write more of them. Look in svn_ra.h
more more information.
> Ofcourse this should _not_ be stored in the wc.
Right now, all authentication info is saved in SVN/auth/, which is
chmod'ed to 0700. Is that not safe enough for you? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Auth in ra_dav
Posted by Sander Striker <st...@apache.org>.
Hi,
Is it going to be possible to write a different authentication
mechanism than something that requires a username/password?
I'm talking about a plugin that might take a username/ssh private
key file. Ofcourse this should _not_ be stored in the wc. I
would be willing to invest some time in writing this if I get
a bit of guidance :)
But probably this is not something for 1.0...
Sander
> cmpilato@collab.net writes:
>
> > Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> >
> > > So today was the first time I have built/run subversion in a little
> > > while, = and I went to do a couple of things, and found that I can't
> > > do anything vi dav, because I don't know how to authenticate myself.
> > > What do I have to do to m= ake subversion let me do stuff to the
> > > repository.
> >
> > What kind of problems were you seeing? You didn't bail at the first
> > sign of username prompt, did you, because I don't think we actually do
> > anything with the username and password currently.
>
> Except store it in the working copy.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auth in ra_dav
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
>
> > So today was the first time I have built/run subversion in a little
> > while, = and I went to do a couple of things, and found that I can't
> > do anything vi dav, because I don't know how to authenticate myself.
> > What do I have to do to m= ake subversion let me do stuff to the
> > repository.
>
> What kind of problems were you seeing? You didn't bail at the first
> sign of username prompt, did you, because I don't think we actually do
> anything with the username and password currently.
Except store it in the working copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Auth in ra_dav
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Thu, Aug 23, 2001 at 04:12:50PM -0400, Kevin Pilch-Bisson wrote:
> Although apache 2.0 doesn't seem to work for me :(
>
snip...
> And now I am getting:
> [Thu Aug 23 16:11:42 2001] [notice] child pid 11076 exit signal Segmentation fault (11)
>
> in error_log, whenever I try to do anything.
>
Alright, the problem seems to be that once in the distant past I followed
dav-setup, and made a prefork-mpm apache, then removed that from my configure.
So now, my installed directory had problems, because parts were prefork, and
parts were threaded. All seems to be good now.
Thanks for the quick replies.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Auth in ra_dav
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Thu, Aug 23, 2001 at 03:09:41PM -0500, cmpilato@collab.net wrote:
> Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
>
> > So today was the first time I have built/run subversion in a little
> > while, = and I went to do a couple of things, and found that I can't
> > do anything vi dav, because I don't know how to authenticate myself.
> > What do I have to do to m= ake subversion let me do stuff to the
> > repository.
>
> What kind of problems were you seeing? You didn't bail at the first
> sign of username prompt, did you, because I don't think we actually do
> anything with the username and password currently.
Sorry, I guess it has been too long indeed!! I forgot that I have
apache2 running on a port other than 80. I was trying to get my regular
apache to serve svn requests. :)
Although apache 2.0 doesn't seem to work for me :(
BTW, the error was:
kevin@pilchie:~/projects/svn-test [621]$ ls
repos/ wc-local/
kevin@pilchie:~/projects/svn-test [622]$ svn co http://localhost/svn/repos -d wc-dav
Username:
Password:
apr_error: #20014, src_err 0 : <Error string not specified yet>
The OPTIONS response did not include the requested activity-collection-set.
kevin@pilchie:~/projects/svn-test [623]$
And now I am getting:
[Thu Aug 23 16:11:42 2001] [notice] child pid 11076 exit signal Segmentation fault (11)
in error_log, whenever I try to do anything.
(Linux 2.4 todays versions of both apache and svn.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Auth in ra_dav
Posted by cm...@collab.net.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> So today was the first time I have built/run subversion in a little
> while, = and I went to do a couple of things, and found that I can't
> do anything vi dav, because I don't know how to authenticate myself.
> What do I have to do to m= ake subversion let me do stuff to the
> repository.
What kind of problems were you seeing? You didn't bail at the first
sign of username prompt, did you, because I don't think we actually do
anything with the username and password currently.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org