[PATCH] Fix bug #9932 - Currently the maximum number of aces in an SD is limited to 1000, but Microsoft supports around 1800

Scott Lovenberg scott.lovenberg at gmail.com
Mon Jun 10 11:01:10 MDT 2013


On Jun 10, 2013, at 12:00 PM, Jeremy Allison <jra at samba.org> wrote:

> On Sat, Jun 08, 2013 at 10:06:24PM -0400, Simo wrote:
>> On 06/08/2013 06:08 PM, Richard Sharpe wrote:
>>> On Fri, Jun 7, 2013 at 4:42 PM, Andrew Bartlett <abartlet at samba.org> wrote:
>>>> On Fri, 2013-06-07 at 19:40 -0400, Scott Lovenberg wrote:
>>>>> On Jun 7, 2013, at 7:33 PM, Jeremy Allison <jra at samba.org> wrote:
>>>>> 
>>>>>> Richard, please review and push if you're ok with it.
>>>>>> 
>>>>>> Jeremy.
>>>>>> <0001-Fix-bug-9932-Currently-the-maximum-number-of-aces-in.patch>
>>>>> I had a bit of a side bar with Richard about this a while ago. IIRC, I thought it depends on the size of the ACEs in the ACL?  That is, the aggregate size of the ACL. :/
>>>> The limit in the IDL was added as an attempt to avoid allocating
>>>> infinite amounts of memory attempting to parse structures that are not
>>>> plausible.  Changing it a little shouldn't hurt, but I agree this might
>>>> not be how windows enforces this.
>>> The evidence we have is that the clients enforce this. If you build an
>>> ACL that will result in an SD larger than 64kiB it refuses to even let
>>> the SD hit the wire.
>>> 
>>>> From that perspective, 1,800 is not quite correct because we have seen
>>> ACLs with 1818 succeed. That, of course, relates to the fact that
>>> S-1-5-21-x-y-z-rid is larger than S-1-1-0 or S-1-5-32-544 etc.
>> Shouldn't the fix then calculate the maximum possible number of ACEs
>> with the smallest SID on all of them that can fit in 64KiB and use that
>> as the max number and at the same time add some code to check the size
>> of the ACL and correctly refuse anything bigger than what the actual
>> underlying file system can accept.
> 
> Yes - it should certainly do this. However, until that gets
> done is this small fix an acceptable intermediate step ?
> 
> Jeremy.

Seeing as it's _closer_ to Windows semantics than what is currently in place, I'm on board FWIW.  :)


More information about the samba-technical mailing list