[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "witty subject line about logging feature"

From: Michael Sinz <michael.sinz_at_gmail.com>
Date: 2005-07-22 22:49:36 CEST

On 7/21/05, Greg Hudson <ghudson@mit.edu> wrote:
> On Thu, 2005-07-21 at 17:57 -0500, Ben Collins-Sussman wrote:
> > A. Make it easy for any svn-related program to log messages to a
> > common place -- not just server implementations, but *any*
> > svn-related program. This makes it easier to find/manage logs,
> > and rotate them.
>
> I'm skeptical of this design goal, because normally logging only makes
> sense when you're a server accepting requests from a client. Although
> people might be interested in having a log of the svnadmin or svnlook
> actions performed on a repository, I don't think that's any more worthy
> of an application's attention than it would be for a program like "ls"
> to log. Normally one uses process accounting or a similar facility to
> accomplish that goal.

The goal should be that anything that plays with the repository should
log - the only problem is that we have the file:// access method, which
is direct playing with the repository and thus is, by and of itself, a major
security issue. Personally, I would not depend on file:// access logs
for anything critical as there is nothing that would enforce correctness.

In all other cases (non-file:// access), the logs should be enforced and
controlled by the server - the client should have no ability to change
or otherwise influence the logging other than the fact that SVN operations
are being done and logged.

> There are a few things that can go wrong with logging outside of
> non-network requests:
>
> * The person running the program can circumvent the log by removing
> the logging functionality from the code. So administrators might think
> they're getting a complete log, but they aren't necessarily.

Or, even worse, can poison the log with false or disruptive data.
A log is only as useful as it is trustable. If raw data from the outside
comes into the log, well...

> * The person running the program may not have access to the log file,
> which can result either in an incomplete log or gratuitous blocking of
> the requested action.

Users should never have write access to log files. This would be a major
security issue. (Well, other than root/admin/super-users - but then those
users already have the keys to the kingdom...)

-- 
Michael Sinz               Technology and Engineering Director/Consultant
"Starting Startups"                          mailto:Michael.Sinz@sinz.org
My place on the web                      http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 22 22:50:15 2005

This is an archived mail posted to the Subversion Dev mailing list.