Does this address your issue? This is from From Article ID: 310316:
"How permissions are handled when you copy and move files and folders"
I haven't tried it myself.
"You can modify how Windows Explorer handles permissions when objects
are moved in the same NTFS volume. As mentioned, when an object is moved
within the same volume, the object preserves its permissions by default.
However, if you want to modify this behavior so that the object inherits
the permissions from the parent folder, modify the registry as follows:
1. Click Start, click Run, type regedit, and then press ENTER.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
3. On the Edit menu, click Add Value, and then add the following
registry value:
Value name: MoveSecurityAttributes
Data type: DWORD
Value data: 0
4. Exit Registry Editor.
5. Make sure that the user account that is used to move the object
has the Change Permissions permission set. If the permission is not set,
grant the Change Permissions permission to the user account.
Note The MoveSecurityAttributes registry value only applies to Windows
XP and to Windows Server 2003. The value does not affect Windows 2000."
-----Original Message-----
From: Ben Scott [mailto:[email protected]]
Sent: Wednesday, April 28, 2010 10:31 PM
To: NT System Admin Issues
Subject: Re: The finer points of NTFS ACLs (was: Software installs on
new PCs)
On Wed, Apr 28, 2010 at 5:35 PM, James Rankin <[email protected]>
wrote:
> I didn't know that you were asking users to actually perform the
> move....one of the benefits of us being a fairly small and linear
> organisation is that stuff doesn't tend to get moved from drive to
drive too often.
If it gets moved from "drive" to "drive", Windows actually implicitly
does a copy-then-delete, so that's fine. It's moving between folders on
the same "drive" that causes the problem.
For example, say we've got a folder like this, for our official
Quality Management System documentation:
N:\Quality\QMSDocs\
Under there, we have sub-folders:
N:\Quality\QMSDocs\Drafts\
N:\Quality\QMSDocs\Current\
N:\Quality\QMSDocs\Obsolete\
Everyone in the company can read "Current", but only members of the
"Quality Staff" group can read "Drafts" or "Current". When a draft is
approved, the doc editor moves the file from "Drafts" to "Current".
Problem is, Windows does not update the ACL on the file. So nobody in
the rest of the company can open the file. The doc editor has to
explicitly do a copy-then-delete. Giant pain in the butt.
I imagine this could be a security exposure, too. If you've got
Bypass Traverse Checking turned on (which is the default), you can open
a file as long as you know its name. So, hypothetically, some
unsuspecting user could move a file from a internal-public folder to a
nominally restricted folder. But Windows would keep the old ACL.
Someone could guess the new location and still read/modify the file.
This is a fairly unlikely scenario, I think, but when it comes to
security, unlikely scenarios have a disturbing tendency to pay off.
All Microsoft would need to do to fix this would be to make the "move"
system call check the ACL of the item being moved, remove any inherited
ACEs, and if it isn't set to block inheritance, propagate ACEs from the
new container. If you're worried about unneeded write I/O, have it only
write the new ACL if it differs from the old ACL.
Make it a non-default option if you're concerned about performance or
backwards compatibility or whatever.
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
Confidentiality Notice:
----------------------------------
This communication, including any attachments, may contain confidential
information and is intended only for the individual or entity to whom it is
addressed. Any review, dissemination, or copying of this communication by
anyone other than the intended recipient is strictly prohibited. If you are not
the intended recipient, please contact the sender by reply email, delete and
destroy all copies of the original message.
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
