From dev-return-18710-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sun Jul 29 21:54:31 2007 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 15965 invoked from network); 29 Jul 2007 21:54:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Jul 2007 21:54:29 -0000 Received: (qmail 3935 invoked by uid 500); 29 Jul 2007 21:54:29 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 3897 invoked by uid 500); 29 Jul 2007 21:54:28 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 3886 invoked by uid 99); 29 Jul 2007 21:54:28 -0000 Received: from Unknown (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 29 Jul 2007 14:54:28 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.202.165.183] (HELO smtpauth03.prod.mesa1.secureserver.net) (64.202.165.183) by apache.org (qpsmtpd/0.29) with SMTP; Sun, 29 Jul 2007 21:54:23 +0000 Received: (qmail 22793 invoked from network); 29 Jul 2007 21:54:02 -0000 Received: from unknown (24.15.193.17) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 29 Jul 2007 21:54:02 -0000 Message-ID: <46AD0C79.1030906@rowe-clan.net> Date: Sun, 29 Jul 2007 16:54:01 -0500 From: "William A. Rowe, Jr." User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Erik Huelsmann CC: Brad Stiles , users@subversion.tigris.org, APR Developer List Subject: Re: SVN CLI and Windows security References: <20070725182304.IJIE15943.ibm66aec.bellsouth.net@mail.bellsouth.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Erik Huelsmann wrote: > On 7/25/07, Brad Stiles 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. This presumes it's an error at all. The _TRUENAME flag tells us that we MUST use the canonical path. The *only* way to accomplish this is with read/traverse access through the file path. The arguements for this approach is that an app (such as a server) often needs to deal with the single proper name of a resource. Program Files may be Progra~1, it may also be Progra~2, or on netware, ProgramF. > 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. Of course it won't be fixed, because it is not broken. Bill