On 28 September 2013 22:00, <jason_at_binarycoder.net> wrote:
> In a working copy, different directories may require different Windows
> permissions (access control lists). For example, some might contain
> code or data to be accessed by Windows services. Concretely, the
> Windows service might be a web server and the directory might contain
> HTML files. For convenience in this reproduction, assume the service
> runs as "LOCAL SERVICE", an account that comes with Windows. Of
> special note (but not shown in the following example), different
> portions of the working copy may require different permissions. For
> example, this might be because there are several different Windows
> services involved. For illustration, let's call the working copy root
> wc and a directory requiring the permissions wc\a.
>
> I don't expect (or event want) svn to store Windows permission
> information in its repository, but I find it undesirable that svn
> "arbitrarily" interferes with any manually applied permissions,
> particularly file permissions inherited from parent directories. svn
> seems to get itself into trouble when it performs what to the user is
> logically a file "create" through a physical file "move". This is
> because Windows has potentially surprising behavior in this case where
> it does not recalculate the inherited permissions on the file according
> to its new parent directory. This may appear to be an OS bug in the
> MoveFile/MoveFileEx API, but Microsoft blogger Raymond Chen does an
> excellent job explaining how things got to be this way (related to
> Windows "hard link" support!). The blog post is: "Moving a file does
> not recalculate inherited permissions" at
> http://blogs.msdn.com/b/oldnewthing/archive/2006/08/24/717181.aspx.
>
> Raymond Chen describes a solution: After performing the
> MoveFile/MoveFileEx, to "... recalculate [the file's access control
> entries] from the destination's inheritable properties ... [c]all the
> SetNamedSecurityInfo function, specifying that you want an empty,
> unprotected DACL." The reason I think this would be the correct
> handling is because the move is an implementation detail. The fix
> causes the permissions to end up to what they would have been had
> CreateFile been used instead of MoveFile. The follow shows how to
> reproduce. The call to icacls /reset is analogous to
> SetNamedSecurityInfo with a NULL DACL.
>
I see two possible solutions for this problem:
1. Use hTemplate argument in CreateFile call when temporary file is created
2. Created temporary file along original file to be replaced instead
of .svn/tmp in working copy root
Option (1) is hard to because APR abstraction, while (2) should be
easier but solve only problem when file itself doesn't have specific
permissions.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2013-09-28 20:46:57 CEST