Michael R Sweet wrote:
> Michael Sinz wrote:
>>> At least you'd be starting with existing, working code that is
>>> well-suited to different kinds of logging...
>> Ahh, but this still does not address the issue of the client code
>> (svn/etc) doing the logging when the access is via file:// - or maybe
>> it does with the extra demand that file:// access use must also give
>> full write access to the log files to all users. (Even if they only
>> have read access to the repository)
> Well, a couple thoughts on that:
> 1. If you want logging with file:// access, you are already
> setting up permissions properly to provide file:// access,
> so this isn't a large barrior IMHO.
> 2. If you care about the security/validity of the log, then
> you'll likely use svnserve or mod_dav so that users don't
> need direct access to the log file(s).
> In short, I don't think write access to log files is a major
> issue for file:// usage.
I think you missed the key statement - write access would be needed
even if read-only access to the repository. But, as you state, if you
have any real need/concern for the log, then file:// access is out of
the question anyway. However, one would need to understand that without
some other tools, this would make svn+ssh:// also fall into this case
as the locally run svnserve is basically taking svn:// protocol and
converting it into file:// protocol on the machine as the user of the ssh
account. Thus, once again, in order to get logging, each access account
would need full write access to the logs which basically means that they
can not be trusted.
[ Plus, once you get into the situation of the client doing the logging
you have basically given up on being able to trust that log in any way ]
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:email@example.com
My place on the web http://www.sinz.org/Michael.Sinz
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jul 25 05:48:36 2005