[RFC] Authz_svn support for svnserve/file

[Marcus Rueckert <da...@web.de>]

hi,

I just wonder how much it would take to add authz_svn support to  
svnserve/file?
I know there are long term plans to do so.

My questions now are:

Should we create something like libsvnauthz?
Can we push that in libsvnrepos? (it would give us path based auth for  
file://)
What are the speed impacts?
How to make it optional if we push it into libsvnrepos?
Are there any other options you might prefer? (read-hooks)
What milestone can this be put in?

just looking for comments

darix

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [RFC] Authz_svn support for svnserve/file

[Greg Hudson <gh...@MIT.EDU>]

On Sun, 2005-05-01 at 17:55, Marcus Rueckert wrote:
> I just wonder how much it would take to add authz_svn support to  
> svnserve/file?

Mostly, I think it would be pretty straightforward:

  * Move the file-processing logic from mod_authz_svn to libsvn_repos. 
libsvn_repos would not be doing any enforcement, just providing the
routines to parse and query an authz file.  (There's an argument for
putting this in libsvn_subr instead, but I don't think it's a compelling
one.)

  * libsvn_repos already has callbacks to check read access during an
update etc..  Add similar callbacks to check write access in the commit
editor.

  * In svnserve, add calls to the new authz routines, through a
combination of the libsvn_repos callbacks and just calling to check (for
instance, check_path wouldn't rely on callbacks; it would just check).

There is some room for improved quality of implementation here; unlike
mod_authz_svn in its current form, we could add a way to distinguish
between "all authenticated users" and "anyone at all, authenticated or
not" (perhaps "*" and "**" in the authz file), and perform
authentication challenges when an anonymous user runs into a path they
can't access.  However, that presents a bunch of technical hurdles.  The
authz-processing routines would need to be able to query for whole
subtrees (which precludes ever adding wildcard support to the authz
file, I think) so that we can check in advance if an update can succeed;
and while the protocol allows a commit to do an authn challenge at the
end, when it knows all the paths which are to be modified, the code
would need to be restructured a bit to be able to perform that authn
challenge before finalizing the transaction.

So, probably best to punt on that part.  If people want path-based
authorization for read access, for instance, they'll have to force all
users to authenticate for read access, and create a guest user.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [RFC] Authz_svn support for svnserve/file

[Ben Collins-Sussman <su...@collab.net>]

On May 1, 2005, at 4:55 PM, Marcus Rueckert wrote:

>
> hi,
>
> I just wonder how much it would take to add authz_svn support to 
> svnserve/file?
> I know there are long term plans to do so.
>
> My questions now are:
>
> Should we create something like libsvnauthz?
> Can we push that in libsvnrepos? (it would give us path based auth for 
> file://)
> What are the speed impacts?
> How to make it optional if we push it into libsvnrepos?
> Are there any other options you might prefer? (read-hooks)
> What milestone can this be put in?
>
> just looking for comments
>

Start by reading this document which explains the authz that already 
happens in libsvn_repos.  It's um.... complex.

    http://svn.collab.net/repos/svn/trunk/notes/authz_policy.txt


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [RFC] Authz_svn support for svnserve/file

[Greg Hudson <gh...@MIT.EDU>]

I may be contradicting some of what I said earlier, since I didn't
bother to go back and look what I said last time around.

On Thu, 2005-06-02 at 17:57 +0200, David Anderson wrote:
>   * Modify mod_dav_svn to use the authz routines from libsvn_repos.

It might be easier to skip this, and just make mod_authz_svn use the
routines from libsvn_repos.  (That assumes we can provide APIs suitable
for mod_authz_svn to use, i.e. ones where you don't have to pass a
repository object and can instead pass the location of the access
control file.  I don't see any major obstacle there.)

In the long run, it would be more consistent to make path-based access
control part of libsvn_repos and make all the RA layers find the file in
the same way.  But it would also be less flexible, and would represent a
behavior chance in mod_dav_svn.  Also, in the long run we may have an
FS-based acl system which deprecates path-based access control.  So it's
not necessarily worth the pain and effort to make all the access methods
consistent.

>   * Add write access callbacks in libsvn_repos. Why aren't there already 
> callbacks there?

mod_dav_svn doesn't use the libsvn_repos commit editor, so there hasn't
been a motivation to put access callbacks there yet.  Commits over DAV
are done through a series of discrete HTTP operations, which can be
checked at the mod_authz_svn level with no help from libsvn_repos.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [RFC] Authz_svn support for svnserve/file

[David Anderson <da...@calixo.net>]

> Ah, sounds like you've already filled out a formal app, then.  Good.
> (I'll see it eventually, as will others, I just haven't browsed the
> applications yet.)

Should I resubmit to include the extra info (the faq of SoC now states 
this is possible), or would the Subversion mentors relay extra info (ie. 
commitments to the task) to google if the task is approved by Subversion?
As I understand it, google has the final say after each project 
pre-approves applications, so in that respect any research I'd have 
already done when they start reviewing applications would be beneficial 
to me.

- Dave.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [RFC] Authz_svn support for svnserve/file

[kf...@collab.net]

David Anderson <da...@calixo.net> writes:
> > Should I resubmit to include the extra info (the faq of SoC now states
> > this is possible), or would the Subversion mentors relay extra info (ie.
> > commitments to the task) to google if the task is approved by Subversion?
> 
> Reply to self: I resubmitted giving pointers to this thread and
> additional bio info.

Great, thanks!

(By the way, we're still waiting for apps to come in, so it may take
us a while before we review them all and respond.)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [RFC] Authz_svn support for svnserve/file

[David Anderson <da...@calixo.net>]

> Should I resubmit to include the extra info (the faq of SoC now states
> this is possible), or would the Subversion mentors relay extra info (ie.
> commitments to the task) to google if the task is approved by Subversion?

Reply to self: I resubmitted giving pointers to this thread and 
additional bio info.

*returns to reading the svn source code*

- Dave.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [RFC] Authz_svn support for svnserve/file

[kf...@collab.net]

David Anderson <da...@calixo.net> writes:
> Okay, here goes. On a `contributing coder` note, feedback,
> suggestions, proposals etc. are of course most welcome. On a `SoC
> candidate` note, please let me know wether this mail constitutes
> adequate preliminary implication (as outlined in Karl Fogel's
> announcement of SoC). I'm ready to do the work on this, I just need to
> know how to convince you of it ;-)

This mail is adequate for the Subversion project, yes.  You also need
to fill out http://code.google.com/soc_application.html, of course.
On that form, in the "project description" field, I'd say summarize
what you're proposing, and include links to
http://subversion.tigris.org/project_tasks.html#svnserve_authz and to
this mail thread.
 
> As I said in my intro mail (and SoC application for those of the team
> who get to read those), I'd like to work on implementing path-based
> access control in svnserve.

Ah, sounds like you've already filled out a formal app, then.  Good.
(I'll see it eventually, as will others, I just haven't browsed the
applications yet.)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [RFC] Authz_svn support for svnserve/file

[David Anderson <da...@calixo.net>]

Hi,

Okay, here goes. On a `contributing coder` note, feedback, suggestions, 
proposals etc. are of course most welcome. On a `SoC candidate` note, 
please let me know wether this mail constitutes adequate preliminary 
implication (as outlined in Karl Fogel's announcement of SoC). I'm ready 
to do the work on this, I just need to know how to convince you of it ;-)

This is a preliminary "get together and work out what we want doing" 
kind of mail, so if you have specific requirements for this authz that 
you'd like implemented, now would be the time to speak up.

As I said in my intro mail (and SoC application for those of the team 
who get to read those), I'd like to work on implementing path-based 
access control in svnserve.

Please note that I say 'in svnserve'. There is also a proposal to get 
path-based access control directly in the fs core library floating 
around; I am not proposing to do this. It would be nice to get that 
support in the core fs, but as far as I can see, opinions are divided as 
to wether it's worth the bother, and working on such a project would be 
somewhat overboard for first contributions.

So, path-based access control in svnserve, ie. offering an equivalent to 
what can be done with mod_dav_svn and svn_authz. Greg Hudson posted a 
list of things to be done, so until I have the time to have a detailed 
look at the source code for this and lay out more specifically the 
changes, I'll follow his guidelines.

  * Move the authz code to libsvn_repos. This is fairly straightforward 
in terms of code shifting, unless we take this opportunity to change the 
behaviour of authz (I'll get back to this). This would mean each 
repository gets its own authz file (listed in the repository config?) 
and the authz functions just take a handle to the repository and from 
there locate the authz file and perform the checks.

  * Modify mod_dav_svn to use the authz routines from libsvn_repos. If 
the per-repository authz file is defined in the repository configuration 
(ie. the conf/ subdirectory of a repository), work out wether the Apache 
config can override it through apache config directives, or wether we 
decide that the authz file (or the path to it) belongs in conf/ and 
nowhere else.

  * Add write access callbacks in libsvn_repos. Why aren't there already 
callbacks there? Because mod_dav_svn checks the credentials at a higher 
level, before invoking libsvn_repos routines? If so, the modification to 
mod_dav_svn may be more significant than I'd at first thought.

  * Modify svnserve to actually enforce the authz access control, 
through the use of callbacks or direct checking.

Looking at this, it all seems fairly straightforward. I would like some 
insight concerning my question about the callbacks, and wether from a 
general point of view anyone sees major problems with these modifications.

Greg's mail also speaks of modifying the current authz behaviour in some 
ways. My primary concern as far as this goes would be working out some 
way of optimising the authz process, to lessen the performance hit of 
activating path-based access control. I have a few ideas on the subject, 
but I'll keep them in reserve until I see exactly how authz interacts 
with the rest of svn.

Optimisation aside, there's the proposal to add features to the authz 
process. Greg named distinguishing "any authenticated user" and "any 
user at all". I personally feel that the "any authenticated user" 
behaviour can currently be satisfactorily emulated by the use of groups 
(even better in some ways, for an acl file spanning multiple projects) 
if the enhanced syntax proves too bothersome to implement. But maybe I'm 
missing something here.

Are there any other enhancements to authz that people would like? If 
they don't require major design work (or if someone more experienced is 
willing to help me with the design), I could look into implementing them 
as a part of this task.

That's mostly it for the time being. I've started reading HACKING and 
exploring the source code for the relevant components of Subversion. 
Once I've gained a little more insight as to how things currently work I 
can start bashing out a more detailed implementation plan.

To conclude, a few words about Summer of Code. As I said, I applied to 
do all this as a part of this initiative. If my application is rejected 
(a likely occurence, given the half-million people that have probably 
applied ;-) ), I won't be able to work on this during the summer as I'll 
be busy working to earn some money for my studies. That said, I'd still 
like to work on it no matter the final outcome of my application. I've 
been thinking about helping out with svn for some time, and summer of 
code or not, I'll be doing so. It'll just take somewhat longer in the 
'not' case, as I'll be busy elsewhere.

Dave

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [RFC] Authz_svn support for svnserve/file

[David Anderson <da...@calixo.net>]

Hi,

> I just wonder how much it would take to add authz_svn support to  
> svnserve/file?
> I know there are long term plans to do so.

I'm looking into getting access control implemented in svnserve as a 
part of the SoC initiative (which I applied for). Not much else to say 
right now, just a quick word to let people interested in authz for 
svnserve know. I'll follow up later on with questions and proposals I 
have for this feature.

Dave

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org