[SSSD] [PATCH] Clean up kdcinfo and kpasswdinfo files when exiting

Stephen Gallagher sgallagh at redhat.com
Wed May 5 12:18:32 UTC 2010


On 05/05/2010 03:40 AM, Jakub Hrozek wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/04/2010 11:44 PM, Jakub Hrozek wrote:
>> On 05/04/2010 10:54 PM, Stephen Gallagher wrote:
>>> https://fedorahosted.org/sssd/ticket/452
>>
>>
>>> This patch adds a signal handler for SIGTERM that will remove the
>>> kdcinfo.REALM and kpasswd.REALM files before exiting. I had to move the
>>> definition of krb5_ctx into krb5_common.h so I could dereference it to
>>> get the realm name.
>>
>>> I also made the sig_term() function from server.c public, so I could
>>> chain into it once my exit handler is done (to make sure it cleans up
>>> any krb5_child processes that might still be in-progress).
>>
>>
>> Nack, if using kdc for kpasswd operations, ctx->kpasswd_service is NULL,
>> so you would get a segfault.
>>
>> I think the realms for kpasswd and kdc will always be the same, so maybe
>> you can pass the realm as the private_data and avoid exposing the krb
>> context at all?
>
> Also please define sige in sssm_krb5_auth_init()

New patch attached just passes in the realm as the private data of the 
callback. Also, I rebased this patch atop my "Properly set up SIGCHLD 
handlers" patch, as they were in conflict.

In case you're wondering why I didn't use talloc_get_name() in the 
signal callback as is our style, it's because the talloc_strdup() set's 
the context's name equal to the string's value. So I had to just use a 
traditional cast here instead.

-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Clean-up-kdcinfo-and-kpasswdinfo-files-when-exiting.patch
Type: text/x-patch
Size: 4797 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20100505/2959fdd6/attachment.bin>


More information about the sssd-devel mailing list