smb2.acls.ownerrights failure
Shilpa K
shilpa.krishnareddy at gmail.com
Wed Dec 7 11:57:53 UTC 2016
Hi Jeremy,
I agree with you that the test is not complete. First, we wanted to verify
that what was returned matches with what was set. Secondly, I think we
shouldn't be setting owner ACE as we purely wanted to test owner rights
when there is no explicit ACE for owner to grant any access. In any case, I
think the test does show that there is problem in se_access_check() even
though it is not complete. So, yes, it is not ready to be submitted to the
branch.
Thanks,
Shilpa
On Fri, Dec 2, 2016 at 6:30 AM, Jeremy Allison <jra at samba.org> wrote:
> On Thu, Dec 01, 2016 at 10:34:07AM -0800, Jeremy Allison wrote:
> > On Thu, Dec 01, 2016 at 02:43:43PM +0530, Shilpa K wrote:
> > > Hi Jeremy,
> > >
> > > I have pasted below the git diff for samba-master branch.
> >
> > Thanks a *lot*. I'm going to do some work on this to
> > ensure I understand exactly what the semantics of setting
> > an ACE for sid "S-1-3-4" with restricted access, followed
> > by an ACE for the actual owner sid with SEC_RIGHTS_FILE_ALL.
> >
> > There's more clarification I need on that (I'll test
> > against Windows to be sure).
>
> OK, I've run this against Win2K12 and I *think* I see what
> you're trying to do, but IMHO this test doesn't
> do what you think it does :-).
>
> Your test array is:
>
> const struct {
> uint32_t owner_flags;
> uint32_t owner_rights;
> } test_perm[] = {
> {
> 0,
> 0
> },
> {
> SEC_ACE_TYPE_ACCESS_ALLOWED,
> SEC_STD_WRITE_DAC | SEC_STD_READ_CONTROL,
> },
> {
> SEC_ACE_TYPE_ACCESS_ALLOWED,
> SEC_STD_WRITE_DAC,
> },
> {
> SEC_ACE_TYPE_ACCESS_DENIED,
> SEC_STD_WRITE_DAC,
> },
> };
>
> but when you replace the new ACL on the file, you always
> append an owner_sid/SEC_ACE_TYPE_ACCESS_ALLOWED/SEC_RIGHTS_FILE_ALL
> ACE.
>
> sd = security_descriptor_dacl_create(tctx,
> 0, NULL, NULL,
> owner_rights_sid,
> test_perm[i].owner_flags,
> test_perm[i].owner_rights,
> 0,
> owner_sid,
>
> SEC_ACE_TYPE_ACCESS_ALLOWED,
> SEC_RIGHTS_FILE_ALL,
> 0,
> NULL);
>
> This means all of your get/set calls over all of
> these entries always work - they always return
> NT_STATUS_OK. For the whatever you set as the
> first ACCESS_ALLOWED ACE is essentially ignored
> as the logic always gets to the second ACE which
> allows everything.
>
> I'm assuming that's not what you wanted because
> of this if clause:
>
> if (test_perm[i].owner_rights & (SEC_STD_WRITE_DAC |
> SEC_STD_READ_CONTROL)) {
> CHECK_STATUS(status, NT_STATUS_OK);
> } else if (test_perm[i].owner_rights & SEC_STD_WRITE_DAC) {
> CHECK_STATUS(status, NT_STATUS_ACCESS_DENIED);
> }
>
> But this if clause is wrong. The:
>
> } else if (test_perm[i].owner_rights & SEC_STD_WRITE_DAC) {
> CHECK_STATUS(status, NT_STATUS_ACCESS_DENIED);
> }
>
> clause will never be selected. The first clause is selected
> for the last 3 entries in the array (as it gets selected
> if *either* SEC_STD_WRITE_DAC *or* SEC_STD_READ_CONTROL
> are set in the owner_rights field). The only case where
> the first clause isn't selected is in the first entry,
> where owner_flags == 0, owner_rights == 0.
>
> But in that case the second clause *still* isn't selected
> as (test_perm[i].owner_rights & SEC_STD_WRITE_DAC) is false.
>
> If you intended the last case in your array to get NT_STATUS_ACCESS_DENIED,
> sorry - it doesn't (as I've confirmed in wireshark). All these
> cases get NT_STATUS_OK.
>
> I'm not sure if this code is just left over from your
> experiments, or you intended it to show something.
>
> Can you let me know ?
>
> The only part of the test that attempts to show the Samba bug
> is the last part - the :
>
> if((test_perm[i].owner_flags &
> SEC_ACE_TYPE_ACCESS_DENIED)) {
> smb2_util_close(tree, handle);
> io.in.desired_access = 0x00020080;
> io.in.create_disposition = NTCREATEX_DISP_OPEN_IF;
> status = smb2_create(tree, tctx, &io);
>
> code.
>
> This does shows that when an ACL of:
>
> [0] S-1-3-4/DENY_ACE/WRITE_DAC
> [1] <owner>/ALLOW_ACE/SEC_RIGHTS_FILE_ALL
>
> is set, that trying to write a new ACL
> to the file returns ACCESS_DENIED.
>
> However, you didn't open the second handle
> with WRITE_DAC request, so it looks
> to me that the ACCESS_DENIED is due to the
> handle not having WRITE_DAC permission, and
> maybe not the ACL you had set.
>
> Can you explain to me EXACTLY what
> you are trying to do with this test ?
>
> Can you walk me through the logic step
> by step so I understand what the test
> is supposed to do ?
>
> I still think we have a bug here, but
> this isn't the regression test to
> show it.
>
> Cheers,
>
> Jere,y.
>
More information about the samba-technical
mailing list