You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Sander Striker <st...@apache.org> on 2001/08/24 15:40:09 UTC
svn auth, WAS: RE: Auth in ra_dav
[...]
>> 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: [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 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