On 2/4/07, Tom Ketola <tom@solidstatenetworks.com> wrote:
> At 11:09 AM 2/4/2007, David James wrote:
> >On 2/4/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> >>My gut tells me that this a pretty unusual use-case; we've designed
> >>svn's security just around 'read' and 'write' concepts, and 'being
> >>able to see history' falls clearly into the 'read' case in our model.
> >>
> >>In fact, we've bent over backwards to make sure that if a revision
> >>affects paths that are unreadable (to the user running 'svn log'),
> >>then the log info is *not* displayed. The assumption is that log
> >>messages are generally at least as sensitive as the code itself. Log
> >>messages can still give away exactly what people are doing, what
> >>sub-tasks they're working on, and even how they're implementing
> >>things. (Note that the revision itself still shows up in the history,
> >>just without any log message displayed.)
> >
> >Does the current model really make sense? It's certainly possible that
> >users could encode top-secret information in their log messages, but
> >this isn't always the case. For example, the log message "Initial
> >import from CVS" is useful, but isn't top-secret. Even if the code
> >itself is secret, the log message might not be.
>
> This is the case with us for sure. Although you may be able to
> extract some information from the log messages that could be useful,
> overall I'm not really that concerned with it. My concern is the
> source code itself getting out, not how exactly things are
> implemented in our source.
>
> >Permission checks on log messages are also particularly expensive. If
> >you import a million files into a Subversion repository with an
> >"initial import" log message, Subversion will force any user who wants
> >to view that log message to wait for a million Apache permission-check
> >subrequests to finish. I've seen repositories where it takes hours to
> >simply run "svn log" on a single file because the log-message
> >permission checks are so expensive.
> >
> >It might make sense to allow users to configure their log-message
> >permissions separately, so as to avoid this bottleneck, without
> >turning off permissions completely. Perhaps we should simply setup a
> >"SVNLogMessageAuthz Off'" flag? This flag would disable authz for log
> >messages, therefore allowing any user who has any access to the
> >repository to also access log messages. Tom, would this flag help with
> >your use case?
> >
> >(By the way: What happened to the artem-soc-work branch? This branch
> >should substantially improve the performance of log message permission
> >checks.)
>
> Yes, this seems like it should work. Correct me if I'm wrong, but
> using this method, any user that I added into Apache's permissions,
> regardless of whether I added them into the svn authorization file
> would then be able to read log messages? If a user had no account at
> all on our system, then they would be unable to access the database
> at all, and therefore would not be able to read log messages,
> correct? If those cases our true, then your solution would
> definitely address my issue.
Yes, this is correct.
Tom, if you would like to submit a patch to implement this feature,
with an appropriate log message, I would be happy to review it. Just
add me to the CC list when you submit your patch. If you have
questions about how to implement this just send your
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 5 17:44:40 2007