svn commit: samba r20090 - in branches: SAMBA_3_0/source/auth SAMBA_3_0/source/groupdb SAMBA_3_0/source/lib SAMBA_3_0/source/nsswitch SAMBA_3_0/source/passdb SAMBA_3_0/source/rpcclient SAMBA_3_0/source/smbd SAMBA_3_0_24/source/auth SAMBA_3_0_24/source/groupdb SAMBA_3_0_24/source/lib SAMBA_3_0_24/source/nsswitch SAMBA_3_0_24/source/passdb SAMBA_3_0_24/source/rpcclient SAMBA_3_0_24/source/smbd

James Peach jpeach at samba.org
Sun Dec 10 01:05:42 GMT 2006


On 09/12/2006, at 3:52 PM, Jeremy Allison wrote:

> On Sat, Dec 09, 2006 at 03:13:10PM -0800, James Peach wrote:
>>
>> Thanks Jeremy. One thing - in create_token_from_username, the gids
>> array can be allocated on either tmp_ctx or mem_ctx. tmp_ctx is
>> destroyed on exit, but mem_ctx is not, and can be the null context.
>> Do you need to explicity free gids?
>
> The cases when create_token_from_username() is called with
> the null context are both in smbd/service.c. In these cases
> the allocated sids (not gids actually) array is assigned to
> conn->nt_user_token, which is freed with TALLOC_FREE() in
> conn_free() in smbd/conn.c.

But what happens to the gids that were allocated on mem_ctx by  
pdb_default_enum_group_memberships? Previously they were allocated on  
tmp_ctx which is destroyed on the way out. Now they are just left  
dangling. Am I missing something here?

> Actually there is one talloced thing that should be freed,
> and that's the "found_username" string. I'll fix this.

I'd argue that if create_token_from_username fails it should clean  
found_username itself. Callers shouldn't have to do this.

--
James Peach | jpeach at samba.org




More information about the samba-cvs mailing list