Bug #3024 still trivial, still applies, still not in svn :-(

Johann Hanne jhml at gmx.net
Mon Apr 30 14:12:52 GMT 2007


On Monday 30 April 2007 18:20, Jelmer Vernooij wrote:
> Hi Johann,
>
> On Mon, 2007-04-30 at 13:31 +0200, Johann Hanne wrote:
> > On Monday 30 April 2007 09:18, Jelmer Vernooij wrote:
> > > Hi Johann,
> > >
> > > Johann Hanne wrote:
> > > > I just tested 3.0.25rc3 and found out, that bug #3024 is still in.
> > > > Moreover, the proposed patch still applies and it still fixes the
> > > > bug. I'm getting a little desperate on this. What's the problem? I'd
> > > > do anything I can to get it applied?!
> > >
> > > That patch doesn't look right. If winbindd_fill_pwent returns non-zero,
> > > then user_list_ndx won't be incremented and since it will always be
> > > incremented by at most 1 every time the loop is run, it's basically the
> > > same as writing:
> > >
> > > while(1) {
> >
> > I don't think so. Even if user_list_ndx gets never incremented due to
> > winbindd_fill_pwent() errors,
> > --
> >                         /* No more domains */
> >
> >                         if (!ent)
> >                                 break;
> > --
> > will jump out of the loop as soon as all users have been received.
>
> Sure, but that would also happen with while(1) {. My point is, I don't
> think the condition in while() will ever be false so it has the same
> effect as while(1).
Ah, ok. But I don't think that's the case:
--
num_users = MIN(MAX_GETPWENT_USERS, state->request.data.num_entries);
--
This sets the maximum number of users to MAX_GETPWENT_USERS, even if there are 
available more than that. And "user_list_ndx < num_users" limits the number 
of users actually retrieved so that the malloc'ed array doesn't overflow.

I've added the following debug output to make sure that this is actually true:
--
                        user_list_ndx++;

DEBUG(1, ("***** user_list_ndx=%d, num_users=%d *****\n", user_list_ndx, 
num_users));

                        state->response.data.num_entries++;
                        state->response.length +=
                                sizeof(struct winbindd_pw);
--
This results in the following debug output (with
#define MAX_GETPWENT_USERS 10):
--
  ***** user_list_ndx=1, num_users=10 *****
  ***** user_list_ndx=2, num_users=10 *****
  ***** user_list_ndx=3, num_users=10 *****
  ***** user_list_ndx=4, num_users=10 *****
  ***** user_list_ndx=5, num_users=10 *****
  ***** user_list_ndx=6, num_users=10 *****
  ***** user_list_ndx=7, num_users=10 *****
  ***** user_list_ndx=8, num_users=10 *****
  ***** user_list_ndx=9, num_users=10 *****
  ***** user_list_ndx=10, num_users=10 *****
  ***** user_list_ndx=1, num_users=10 *****
  ***** user_list_ndx=2, num_users=10 *****
  ***** user_list_ndx=3, num_users=10 *****
  ***** user_list_ndx=4, num_users=10 *****
  ***** user_list_ndx=5, num_users=10 *****
  ***** user_list_ndx=6, num_users=10 *****
  ***** user_list_ndx=7, num_users=10 *****
  ***** user_list_ndx=8, num_users=10 *****
  ***** user_list_ndx=9, num_users=10 *****
  ***** user_list_ndx=10, num_users=10 *****
  ***** user_list_ndx=1, num_users=10 *****
  ***** user_list_ndx=2, num_users=10 *****
  ***** user_list_ndx=3, num_users=10 *****
  ***** user_list_ndx=4, num_users=10 *****
  ***** user_list_ndx=5, num_users=10 *****
  ***** user_list_ndx=6, num_users=10 *****
--
I.e. we have a total of 26 (mapped) users, and the first two times the while 
loop gets stopped by "user_list_ndx < num_users" being false. The third time 
it gets stopped by "if (!ent) break;".

...or am I still missing the point...??

Chers, Johann


More information about the samba-technical mailing list