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
Received on Thu Jun 2 18:19:40 2005