severity 428194 minor
thanks
* Peter Samuelson:
> [Florian Weimer]
>> Subversion 1.4.4 has been released, containing some security fixes:
>>
>> * fixed: security flaw in 'svn prop*' commands [CVE-2007-2448]
>> (r25095, -099, -104, -105, -10)
>>
>> I haven't yet figured out, what the exact problem is, and
>> subversion.tigris.org appears to be down. Sorry.
>
> I'm pretty sure this is Debian bug #419348. The security implication
> is that a user who has SVN repository access but not shell access can
> screw up a repository beyond what is usually possible, making a big
> mess for someone to clean up, especially if you are using the old 'bdb'
> backend. I am not sure whether that counts as a security issue that
> should be fixed in sarge and etch. (After all, the user _is_ already
> trusted to commit to the repository.) But if so, we have patches for
> both.
It turns out that this is a different bug, albeit a minor one as well.
>From the log:
------------------------------------------------------------------------
r25095 | cmpilato | 2007-05-22 02:44:48 +0200 (Tue, 22 May 2007) | 41 lines
Changed paths:
M /trunk/subversion/include/svn_repos.h
M /trunk/subversion/libsvn_repos/fs-wrap.c
M /trunk/subversion/libsvn_repos/log.c
M /trunk/subversion/tests/cmdline/svnsync_tests.py
Add new 'svn_repos_check_revision_access' public function which does
the same kind of access checks that, say, svn_repos_get_logs() does,
determining if a repository revision is fully readable, fully
unreadable, or something in-between.
This is more for the benefit of third party tools like ViewVC and hook
scripts than for Subversion's own internal usage.
As is turns out, this also fixes a minor, edge-case security flaw in
the public functions svn_repos_fs_change_rev_prop(),
svn_repos_fs_revision_prop(), and svn_repos_fs_revision_proplist()
which previously failed to factor in changed-path copyfrom source
paths in their revision readability determination like
svn_repos_get_logs() does. Those aware of the issue think it's a *very
minor* one, and that the benefits of public revisitation of our policy
of including copyfrom-sources in the access determination outweigh the
benefits of secrecy in this case. We have, however, reserved
CVE-2007-2448 for the tracking of this inconsistency (which is, again,
fixed by this commit).
* subversion/include/svn_repos.h
(svn_repos_revision_access_level_t): New (copied with mods from fs-wrap.c).
(svn_repos_check_revision_access): New.
* subversion/libsvn_repos/log.c
(svn_repos_check_revision_access): New.
* subversion/libsvn_repos/fs-wrap.c
(rev_readability_level): Moved (and renamed) to svn_repos.h. All
users updated to match the new public values.
(get_readability): Removed.
(svn_repos_fs_change_rev_prop3, svn_repos_fs_revision_prop,
svn_repos_fs_revision_proplist): Use svn_repos_check_revision_access()
instead of get_readability().
* subversion/tests/cmdline/svnsync_tests.py
(copy_from_unreadable_dir, copy_with_mod_from_unreadable_dir,
copy_with_mod_from_unreadable_dir_and_copy): Tweak tests to not
expect log messages in revisions for which a path is readable but
its copyfrom-path is not.
------------------------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
