On Fri, Jun 10, 2011 at 03:57:19PM +0000, Obaid Farooqi wrote: > Your observation is correct, and it is the case that the > CIFS, SMB or SMB2 server MUST first verify that the > Share.FileSecurity allows the client-supplied > DesiredAccess. If any of the nonzero bits of DesiredAccess > are not permitted for the user by the Share.FileSecurity, > the server MUST fail the request with > STATUS_ACCESS_DENIED.
Thanks. This is for the ntcreate call, right? > Please let me know if it answers your question. If it > does, I'll consider this issue resolved. It does not fully answer it, sorry. Attached find a network trace against the server where user "vlendec" (the one I'm connecting as) does not have the "full access" right as in the last traces. However, in frames 38/39 it seems that I was able to create a new file, giving it a custom security descriptor. I would have thought that when setting secdescs is forbidden then creating a new file would not allow me to set custom file descriptors using the nttrans create call. This way it is possible for a user to circumvent the non-ability to set secdescs by just making a copy into a new file. BTW, the trace is from re-syncing an offline folder after the server came back. Can you explain that or show where this exception is documented? And, will this end up in the documentation somewhere? 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 _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol