---------- Forwarded message ----------
From: David W. Wilson <wilson.d@anseri.com>
Date: Sep 21, 2007 12:11 PM
Subject: RE: Things that mighta made my life easier
To: Matt Sickler <crazyfordynamite@gmail.com>
> > - The SVN guide warned TortoiseSVN+mod_authz_svn users to
> grant
> > read all users read access to the SVN repository root. It seems that
> at
> > least one TSVN feature (the revision graph) requires access to the
> SVN
> > verbose log, and if the user does not have read access to the root,
> they
> > cannot read the log and the revision graph fails (even if they have
> read
> > access for the file they are graphing). The only way around this
> problem
> > seems to be to grant all users read access in the root, and to
> restrict
> > access as necessary in immediate subdirectories of the root. This
> compromise
> > restores TSVN revision graphing at the cost of unprotecting files in
> the SVN
> > root. Unless and until this issue is addressed, users need to know
> how to
> > configure the SVN access file to work around it. I can provide some
> > assistance here.
>
> Go talk to tortoisesvn devs, it's their fault for this one.
Am I talking to an SVN dev? I'll assume so.
So this issue is really the TSVN devs' fault? By implementing the revision
graph code, the TSVN devs were attempting to preserve a very useful and
much-used feature of TCVS, specifically, the ability to display revision
graphs of files. But in SVN, Tortoise+mod_authz_svn cannot access the
information it needs to draw the configuration graph (or construct the log?)
unless the configuration manager jumps through hoops to create a security
hole in the repository.
Now this could be because TSVN is asking for information it doesn't need to
draw its revision graph, but a TSVN dev has told me otherwise. Or it could
be that SVN is lazily depending on the SVN root directory privs to protect
the verbose log, even when the reasonable configuration of mod_authz_svn
results in overrestrictive privs to the log. From my standpoint, though, it
looks like reasonable TSVN functionality requires extraordinary measures,
and it is not clear to me that this is TSVN's fault. I do know this problem
won't be solved by TSVN and SVN devs playing the blame game, which is to
say, it won't be solved at all, consequently, I suggest that the SVN doc
should warn configuration managers about this issue with TSVN.
> > - The SVN guide contained some information about obtaining a
> > compatible mod_auth_sspi module and configuring Win32 domain
> authentication,
> > including an access file example. Maybe (dare I hope) mod_auth_sspi.o
> could
> > even ship with SVN or CSS (Microphobia notwithstanding, a lot of us
> have no
> > choice but to work with Windows).
>
> I think the book assumes that if you are crazy enough to need this,
> you will already know how to do it. Remember, svnbook only explains
> svn and its immediate helpers (apache).
I'm crazy enough to work in a Windows shop because it seems preferable to
working at a retail job as I did for five years prior to my present job. I'm
crazy enough to use SVN+TSVN+mod_authz_svn+mod_auth_sspi because my
security-minded manager ordered me to replace the existing CVS+TCSV system
with something more secure that would play well with the Win32 domains.
Along the way, I faced some unpleasant issues that I felt might have been a
bit easier to deal with if svnbook had covered them. svnbook already has the
standard denial-of-accountability boilerplate, so what's the issue with
including some extracurricular discussions that will potentially save the
users a world of hurt?
But I guess I misjudged the svnbook audience. For a fleeting moment I had
the crazy notion that maybe the part of svnbook about installing and
configuring an SVN server might be directed at configuration managers tasked
with installing and configuring an SVN server (in most cases, quick, fast
and in a hurry). In a fit of insanity, I reasoned that since SVN is
available for, recommended for, and routinely installed on Windows, and
since TSVN is practically SVN's conjoined twin, it might be within the scope
of SVN dev to consider the needs of Windows and/or TSVN users with something
besides disdain, and possibly within the scope of svnbook to at least
acknowledge the SVN server configuration issues that might impact these
users (I have already talked to an svnbook editor who seems more open about
these issues). And because SVN server CMs might possibly have to configure
Apache server root security as well, I crazily entertained the notion that
svnbook might possibly touch on this issue as well, but I guess the correct
view is that slogging through Apache config file doc on a tight deadline is
an SVN server CM rite of initiation.
If svnbook assumes SVN servers won't be installed on Windows, or won't use
Windows domain server authentication, or that SVN users won't use TSVN, or
that SVN CM's are Apache webmasters who don't have deadlines and who savor
web surfing and doc slogging and plugin hunting in order to get an SVN
server up and running, maybe those assumptions might brook re-examination.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Sep 22 01:19:12 2007