Robocopy ignores NTFS security
- From: "NadJ" <NadJ@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 22 Aug 2005 09:02:46 -0700
Robocopy.exe - /MIR switch doesn’t care for NTFS permissions and will delete
your data.
A colleague of mine ran a robocopy copy job from his PC to a network share
on my PC (IP: 10.10.10.14). He wanted to copy a 2Gb folder to my share, which
already contained 1Gb of data. The command on his PC was:
robocopy c:\data \\10.10.10.14\data /MIR /R:0 /NP
He inadvertently left the /MIR switch in from a previous job. For those who
aren’t familiar with the /MIR switch, this switch purges any files at the
destination point that no longer reside in the Source. In other words, if
files contained in the destination do not exist in the source, they are
purged (deleted forever!). It is a handy feature that we have relied on lots
in the past and can basically keep a source and destination in synch with
each other.
My ‘Data’ share is configured as follows:
The share permissions has the Everyone group set to ‘Change’ and no other
permissions on the ACL.
NTFS Security is set to: Network Support Team ‘Read and Execute’ and myself
‘Full Control’ and no other permissions on the ACL, not even the
Administrators group.
Only I am a local Administrator on the machine.
My colleague ran the command and within seconds 1Gb of my data just
vanished. However, Robocopy threw up Access Denied errors when his PC began
copying files over, and rightly so, because I hadn’t yet given my colleague
write permissions on the security tab of the share! Luckily I had a backup
from a few weeks ago. However, I performed further tests, this time
explicitly setting my colleague’s AD account to have deny permissions on the
NTFS Security page and re-ran the command. It did the same thing - just
blitzed my data! But refused him write access.
Intrigued with this behaviour, I investigated further. This time I lowered
the Share permission level to Everyone ‘Read’. And left NTFS Security to
explicitly deny my colleague. This time, he could no longer Purge my data or
write to my share.
This is very very strange. It seems that a remote session of Robocopy is
able to ignore NTFS security on a share when it comes to purging files.
(haven’t tried local access yet) I want those familiar with Robocopy to try
this out for themselves. I have been very thorough with the way I have
security set up, and know for certain I am not making a booboo by failing to
notice elevated permissions elsewhere. I think it’s a major major flaw.
.
- Prev by Date: Re: Shrink Boot Partition in W2K Pro?
- Next by Date: Object crypt32LogoffEvent, EventID 560
- Previous by thread: ADMT Cluster Migration
- Next by thread: Object crypt32LogoffEvent, EventID 560
- Index(es):
Relevant Pages
|
