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

Respecting inherited Windows file permissions on file create



    • Bug
    • Status: Open
    • Critical
    • Resolution: Unresolved
    • 1.8.x
    • ---
    • unknown
    • None
    • Windows 7


      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
      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:

      Original issue reported by jasonkresowaty


        1. 1_SvnInheritedPermsRepro.cmd
          2 kB
          Subversion Importer

        Issue Links



              Unassigned Unassigned
              subversion-importer Subversion Importer
              0 Vote for this issue
              0 Start watching this issue