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