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.
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.)
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 4 19:09:59 2007