apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Huelsmann" <ehu...@gmail.com>
Subject Re: SVN CLI and Windows security
Date Sun, 29 Jul 2007 21:41:01 GMT
On 7/25/07, Brad Stiles <bradstiles@bellsouth.net> wrote:
> I ran into a situation today concerning the command line client and windows security.
 The problem is that the user (a build user performing automated builds on a Windows 2003
VM) attempted to check out a file to a network share and couldn't, apparently because that
user doesn't have access to the share root, even though it does have access to the directory
into which the file should be exported.
> The command I used was:
> svn export http://server/trunk/dir1/dir2/file.txt \\server\share\dir1\dir2\dir3\file.txt
--non-interactive --force
> To which svn.exe responded:
> svn: Error resolving case of '\\server\share\dir1\dir2\dir3\file.txt'
> In that tree, the user has no rights to \\server\share\, but has read/write access to
dir1 and below.  If, as that user, I do 'dir \\server\share', I see nothing, but if I do 'dir
\\server\share\dir1', I see everything just fine.
> Now, in our case, that shouldn't be a problem much longer because the network guys are
in the process of changing the access rights on that directory; the build user really should
have access there.  However, I don't think it's unreasonable to assume that there might be
a legitimate reason for such a restriction.
> Is there something we did wrong here (aside from the rights issue) that would have allowed
the export to happen despite the access rights?  FWIW, 'svn checkout' resulted in the same
type of error.
> When the network guy saw it, he said, "Maybe they're using the old NT4 method of stepping
through the tree, rather than going straight to the location specified."  Is there something
in whatever layer svn is using for this that accesses the tree step by step rather than as
one entity?  And is it worth "fixing" if it is a problem?

Well, it's an error that finds its roots in a call to
apr_filepath_merge with an argument of APR_FILEPATH_TRUENAME. Looking
at that function, it calls apr_filepath_root, which tries to isolate
the root in order to see whether it actually exists. That scheme
breaks down when there are no read/write permissions.

I have no idea whether the APR project feels this is something worth
to be fixed, or even fixeable. I cc'ed their dev@ list, to make them
aware if the weren't already.

Hope that answers your question.



View raw message