[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Respecting inherited Windows file permissions on file create

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Sat, 28 Sep 2013 22:46:04 +0400

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

Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2013-09-28 20:46:57 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.