Bug 2242 - NT_TRANSACT_CREATE should not apply security descriptor (SD) always
Summary: NT_TRANSACT_CREATE should not apply security descriptor (SD) always
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.10
Hardware: All Windows XP
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-13 15:10 UTC by Tom Lackemann
Modified: 2005-08-24 10:17 UTC (History)
0 users

See Also:

Attachments
Check smb_action before applying SD (1.46 KB, patch)
2005-01-13 15:16 UTC, Tom Lackemann 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Lackemann 2005-01-13 15:10:51 UTC 
The routine call_nt_transact_create() in smbd/nttrans.c will always apply the 
security descriptor if the 'params' block contains one but this is not always 
correct. According to M$ documentation for CreateFile under the 
lpSecurityAttributes item:
    CreateFile ignores lpSecurityDescriptor when opening an existing file, but 
    continues to use the other structure members.
So the routine should really check the smb_action and qualify the test on 
FILE_WAS_CREATED; in addition to the other tests.
I have a patch which I'll attach once I submit this.
Comment 1 Tom Lackemann 2005-01-13 15:16:56 UTC 
Created attachment 888 [details]
Check smb_action before applying SD

The patch includes some extra setup code for set_sd() if the underlying NT ACL
code make use of the granted access rights to determine if it can apply the SD.
 It may not apply to the standard code but I needed it for something I was
working on.
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-02-07 10:56:19 UTC 
jeremy, please look at this when you get a chance.
Comment 3 Jeremy Allison 2005-03-29 19:22:55 UTC 
Applied (finally!) - thanks.
Jeremy.
Comment 4 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:17:26 UTC 
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.