Hi Volker: I will help you with this issue and will be in touch as soon as I have an answer.
Regards, Obaid Farooqi Escalation Engineer | Microsoft Exceeding your expectations is my highest priority. If you would like to provide feedback on your case you may contact my manager at allis...@microsoft.com -----Original Message----- From: Volker Lendecke [mailto:volker.lende...@sernet.de] Sent: Thursday, May 26, 2011 3:30 AM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net; Tom Talpey Subject: [ttal...@microsoft.com: RE: Reminder -- share secdesc and smb2 echo?] Hi, dochelp! Attached find an explanation of the question I have. Summary: I need to know what exact effect the security descriptor attached to a share (not the file system secdesc) has on the access decisions made via SMB. Please find a detailed explanation further down in this forwarded mail. Answering Tom's question: Yes, this is stock W2k8 (no R2). I have not done this against SMB2 earlier with the same results. If required, I can reproduce it to provide traces for SMB2 as well. Thanks, Volker ----- Forwarded message from Tom Talpey <ttal...@microsoft.com> ----- Date: Wed, 25 May 2011 18:22:51 +0000 From: Tom Talpey <ttal...@microsoft.com> To: "volker.lende...@sernet.de" <volker.lende...@sernet.de> CC: Jim Pinkerton <jp...@microsoft.com>, "j...@samba.org" <j...@samba.org> Subject: RE: Reminder -- share secdesc and smb2 echo? Volker, looking at these, I think it is significant enough that you should ask via dochelp, and we'll get you an "official" answer. That also means we'd have the channel to make an official doc change to describe the behavior if that is indicated. Include these traces. I assume this is a stock Windows 2008 install acting as the SMB server? Also, have you tried with SMB2? -----Original Message----- From: Volker Lendecke [mailto:volker.lende...@sernet.de] Sent: Tuesday, May 24, 2011 9:56 AM To: Tom Talpey Cc: Jim Pinkerton; j...@samba.org Subject: Re: Reminder -- share secdesc and smb2 echo? On Mon, May 23, 2011 at 08:30:19PM +0000, Tom Talpey wrote: > 3) On the share security descriptor, I want to avoid confusion so I > wonder if you can repeat the repro steps we discussed at SambaXP. > IIRC, the case was that of a share security descriptor being set to > deny write access, but owners were observed being denied for > write-type operations to their own files within the share? Ok. Lengthy trace (acls.cap). The relevant frames I want to point out are 1229 and 4028. Both are responses to open a text file with WRITE_DAC access mask. The first time it is denied, the second time it is allowed. The only difference is not in the security descriptor of the file itself, but the security descriptor on the share as such. I tried to open the file as the owner, w2k8\vlendec. It should be visible from the respective session setups before. In between those frames, I logged in as Administrator and looked at the secdesc of the share (frame 2511). There you can see in ACE 2 (rid -513) does not contain the WRITE_DAC privilege. In frame 3434 I gave vlendec (rid -1108) an explicit full control, including the WRITE_DAC. I believe this then led frame 4028 to return success instead of NT_STATUS_ACCESS_DENIED as in frame 1229. Unfortunately in the acls.cap I did not include proof that the text file is actually owned by vlendec. You can see this in owner.cap, frame 736. What I want to know is the exact mechanism leading to ACCESS_DENIED in 1229. Is this only for implicit WRITE_DAC, or are other flags affected with the same mechanism? Hope that makes it clear. Thanks, Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen ----- End forwarded message ----- -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen Microsoft is committed to protecting your privacy. Please read the Microsoft Privacy Statement for more information.The above is an email for a support case from Microsoft Corp.REPLY ALL TO THIS MESSAGE or INCLUDE casem...@microsoft.com IN YOUR REPLY if you want your response added to the case automatically. For technical assistance, please include the Support Engineer on the TO: line. Thank you. _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
