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

Simo idra at samba.org
Tue Jun 11 00:07:44 MDT 2013

On 06/10/2013 12:00 PM, Jeremy Allison 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 ?
I see no issue getting closer, but given Richard has seen 1800+ entries, 
maybe we should use an other round number (1900 ? 2000 ?) that is bigger 
than the max ?

I do not have anything against the current patch though.


More information about the samba-technical mailing list