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

[Jeremy Allison]

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.