Re: logging: are we there yet?

On 8/1/05, Ben Collins-Sussman <sussman@collab.net> wrote:
>
> On Jul 27, 2005, at 6:10 PM, Nicolás Lichtmaier wrote:
>
> > Although I'm not a developer I'd like to propose a different approach:
> [...]
> > Local file access is logged two! The argument about it having no
> > meaning... has no meaning! The "security" of the log system would
> > be no better than the security of the repository itself. Somebody
> > who uses file:// access doesn't care about security, and he still
> > may want to see how his repository is used.
>
> As Greg Hudson already said, this is why process accounting tools exist.

<disclaimer>
I've been off list for a couple weeks, and am catching up in bulk, so
please take this as an apology-before-the-fact if I'm rehashing a
point that's been argued in detail in the list already.
</disclaimer>

I'm concerned that this may be too narrow a view of logging (i.e. as a
tool for <nontechnical>auditing</nontechnical>). While it's certainly
true that a log writeable by a local svn client is hackable by a
local, I suspect most local users aren't malicious. Given that, I can
see reasonable, non-sensitive uses for logging of local activity. For
example, it might be useful to know which parts of a repo see the most
activity in order to adjust backup schedules, or the least activity in
order to decide what to archive. Watching patterns of access might
also help guide decisions about splitting or merging repos, updating
hooks, and the like. None of this is particularly sensitive; the
worst you'd get from a hacked log is a suboptimal repo structure.

Depending on the process accounting tools available, this kind of
information might be tough to recover from the outside. (For
instance, noting that the svn executable was invoked, or even that
/path/to/repo was hit, doesn't help all that much if one can't recover
the URL to see what was hit inside the repo.) It also seems a bit the
proverbial elephant gun for the fly: recroding everything select
(all?) users do in order to better manage svn repos may become
unwieldy.

I understand that, under the curent proposal, the interested sysadmin
can simply switch over from file:// access to svn:// access, so this
isn't a showstopper. Therefore, if logging direct access is a major
pain to code, that may be reason enough to skip it. But it does feel
(to me) somewhat incomplete. I think there's advantage, in mindshare
if not in technical capability, to giving the feature as broad a scope
as possible, and letting people restrict it as needed, rather than to
giving the feature as safe a scope as possible, and lettng people work
around its limits for less secure use cases.

Ya $0.02.

-- 
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org