Bug 8797 - Samba does not correctly handle DENY ACEs when privileges apply
Samba does not correctly handle DENY ACEs when privileges apply
Product: Samba 3.6
Classification: Unclassified
Component: File services
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2012-03-06 23:33 UTC by Richard Sharpe
Modified: 2012-03-19 14:11 UTC (History)
0 users

See Also:
rsharpe: review+

A potential fix for this problem (2.72 KB, patch)
2012-03-08 23:47 UTC, Richard Sharpe
no flags Details
gia-am fix for 3.6.x. (3.23 KB, patch)
2012-03-09 23:30 UTC, Jeremy Allison
jra: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Sharpe 2012-03-06 23:33:59 UTC
I have tested this with Windows 2003.

I created a user, user1, and then created a file and on that file I
removed all inherited permissions, then added a Deny Entry for
DOM\Administrator denying WRITE_OWNER. I also took ownership of the
file as user1.

Then I logged out and logged back in as DOM\Administrator. I then
brought up the properties on that file, and selected the Security tab.
It told me that I did not have permissions to view the permissions
info, but that I could take ownership if I wanted. So, I went to
Advanced, took ownership, and saved, and it was all OK.

I believe that this demonstrates that SeTakeOwnershipPrivilege
overrides explicit deny entries in any ACL on the file, and, as a
result, Samba's current implementation of this is incorrect.

That is because, the current code in libcli/security/access_check.c in se_access_check does the following, roughly:

1. Checks if any privileges apply and removes those bits from bits_remaining,

2. Then checks the ACL and accumulates explicitly_denied_bits and removes allowed bits from bits_remaining.

3. After coming out of the loop where the ACL is checked, it does:

        bits_remaining |= explicitly_denied_bits;

        if (bits_remaining != 0) {
                *access_granted = bits_remaining;
                return NT_STATUS_ACCESS_DENIED;

        return NT_STATUS_OK;

However, that will override the check for SeTakeOwnershipPrivilege, for example, or others as well.

I that the correct thing to do is to move all the privilege checks to after we add the explicitely_denied_bits to bits_remaining and just before the done: label.

However, it would be good to get someone else to re-do my test to ensure that I have not made a mistake here. I will also see if I can create an smbtorture or other test that will work against Windows so I can verify this.
Comment 1 Richard Sharpe 2012-03-08 15:49:55 UTC
Since the change here is quite simple, I believe, I will work up a patch later today or tomorrow for review, unless someone else beats me too it.
Comment 2 Richard Sharpe 2012-03-08 23:47:52 UTC
Created attachment 7364 [details]
A potential fix for this problem

The attached patch re-orders the comparisons to be more correct, I believe.

That is, checks for privileges are performed after the ACL has been scanned and the remaining bits updated accordingly.

If privileges allow us to remove all the remaining bits, we are good.
Comment 3 Jeremy Allison 2012-03-09 01:36:03 UTC
Will review this asap..

Comment 4 Jeremy Allison 2012-03-09 22:44:59 UTC
LGTM. Pushing to master and I'll create a git-am fix for 3.6.x and 3.5.x.
Comment 5 Jeremy Allison 2012-03-09 23:30:08 UTC
Created attachment 7366 [details]
gia-am fix for 3.6.x.

Richard's fix for master, applied to 3.6.x.
Comment 6 Jeremy Allison 2012-03-10 00:12:28 UTC
Hmmm. Not a simple backport for 3.5.x. 3.5.x doesn't do so much with privileges anyway, so maybe a 3.6.x-only fix.

Comment 7 Richard Sharpe 2012-03-14 18:19:28 UTC
I tried to mark the 3.6.x patch as reviewed but am not sure if it took.

Anyway: Review: +
Comment 8 Jeremy Allison 2012-03-14 18:24:10 UTC
Didn't take, so marking it + for you.

Re-assigning to Karolin for inclusion in 3.6.next.

Comment 9 Karolin Seeger 2012-03-19 14:11:45 UTC
Pushed to v3-6-test.
Closing out bug report.