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/> ~
