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.
Tom Ketola
Solid State Networks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 6 22:17:45 2007