Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-4432

Respecting inherited Windows file permissions on file create

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: 1.8.x
    • Fix Version/s: ---
    • Component/s: unknown
    • Labels:
      None
    • Environment:

      Windows 7

      Description

      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 wouldn't expect (or even 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. It is
      
      bad form to leave inheritable permissions unpropagated. That this can
      
      happen is poorly understood, and it is difficult to troubleshoot in
      
      the Windows Explorer GUI when this happens.
      
      
      
      svn gets 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.
      
      
      
      The impact of this problem is that I have to follow svn update or
      
      revert operations below directories with inheritable access control
      
      entries with calls to the console command icacls /reset, even though
      
      the directory tree structure where the permissions are actually
      
      assigned was not changed by the svn operation. In practice, this is not
      
      lightning fast because I cannot trust the permissions in the subtree
      
      and recursively reset everything in the the working copy followed by
      
      re-assigning the permissions from scratch which on Windows is
      
      proportional to the number of files in the working copy.
      
      
      
      Commands to reproduce are attached.
      
      
      
      Mailing list discussion:
      
      http://svn.haxx.se/dev/archive-2013-09/0169.shtml
      

      Original issue reported by jasonkresowaty

        Attachments

        1. 1_SvnInheritedPermsRepro.cmd
          2 kB
          Subversion Importer

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                subversion-importer Subversion Importer
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: