icacls silently adds SYNCHRONIZE to DENY ACL and Explorer sometimes asks for that permission
realrichardsharpe at gmail.com
Tue Apr 9 16:28:22 MDT 2013
On Tue, Apr 9, 2013 at 3:11 PM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> On Tue, Apr 9, 2013 at 3:05 PM, Jeremy Allison <jra at samba.org> wrote:
>> On Tue, Apr 09, 2013 at 02:16:09PM -0700, Richard Sharpe wrote:
>>> Hi folks,
>>> I am seeing a weird problem.
>>> This problem came about because a customer is trying to use icacls to
>>> set a DENY:(D,WDAC) entry on a folder. This succeeds, however, if they
>>> access the folder with Windows Explorer while using SMB2, they get
>>> ACCESS DENIED, but if they access the folder with Windows Explorer
>>> while using SMB1 they do not get ACCESS DENIED.
>>> the icacls command used was: icacls z:\some-dir /deny SOME-USER:(D,WDAC)
>>> SYNCHRONIZE always gets added, but icacls refuses to show it.
>>> The problem seems to be that icacls silently adds SYNCHRONIZE along
>>> with DELETE and WDAC to the DENY entry. Over SMB2, explorer asks for
>>> permissions of 0x00100081 while over SMB1 it only asks for 0x00000081.
>>> The above is against Samba 3.6.12+. However, even with Win7 accessing
>>> W2K08R2 via SMB where I have added a deny entry as above, I get ACCESS
>>> DENIED. I will check SMB1 soon.
>>> The icacls command used on the W2K08R2 system was: icacls test_dir
>>> /deny SOME-USER:(D,WDAC)
>>> Has anyone seen this issue before? The only way to avoid getting the
>>> SYNCHRONIZE bit set is to use SDDL it seems (or smbcacls :-)
>> Should we ignore the SYNCHRONIZE bit on access requests ?
> I don't think so. There is a report out there from Microsoft that
> icacls is broken in this regard:
>> Let me have a look at the MS-FSA...
> I am testing now to see if W2K08, when accessed via SMB1 gives the
> same behavior.
> If so, then I think we should do what Windows does. Especially since a
> combination of PowerShell scripting and SDDL will do what the customer
> wants to do, I believe (PS Scripting to get the SID for a user.)
I should have said that I went to MS-DTYP to check the handling of the
SYNCHRONIZE bit in ACCESS_CHECK but there were no exceptions.
I also believe that I now have demonstrated that W2K8 behaves in the
same way over SMB1. That is, access succeeds over SMB1 but is denied
over SMB2. This is really strange.
More information about the samba-technical