Re: svn auth

[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: svn auth

[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

["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