I also saw this on WinITPro (http://www.windowsitpro.com/article/permissions/ntfs-inheritance-rule-c hange.aspx) which is interesting. One of the commenters states that it is only changed when using the GUI, however.
<quote> Until recently, NTFS permissions have followed these inheritance rules: 1. If a file or folder is copied to some other location, it will inherit the new location's NTFS permissions. 2. If a file or folder is moved to some other location on a different disk drive, it will inherit the new location's NTFS permissions. 3. If a file or folder is moved to some other location on the same disk drive, it will retain the original location's NTFS permissions. One of the NTFS inheritance rules changed in Windows 7, Windows Server 2008, and Windows Vista. Now if you move a file or folder, it will inherit the new location's NTFS permissions, even if the new location is on the same disk drive. This is a radical shift that you need to take into account when you're moving files. You can find a reference to this change in the Notes section in the Microsoft article "Inherited permissions are not automatically updated when you move folders". </quote> -----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/> ~
