[SSSD] [PATCHES] Simplify credential krb5 cache manipulation

Sumit Bose sbose at redhat.com
Thu Sep 5 11:47:47 UTC 2013


On Tue, Sep 03, 2013 at 10:07:13PM -0400, Simo Sorce wrote:
> After the recent patches to explicitly enable the KEYRING type in SSSD I
> realized that the code that manipulates ccaches had grown too much, and,
> most importantly, was doing unnecessary operations already performed in
> an abstract way by krb5 functions.
> 
> This patch set mostly addresses ticket #2061
> 
> The aims has been to remove as much as possible type-specific code,
> resorting to type specific behavior only as an explicit exception where
> necessary due to historical or other reasons.
> 
> The combined diff gives a nice total stat of:
>   815 insertions(+)
>   1529 deletions(-)
> 

I really like cleanup that comes with the patches but I would prefer not
to use setresuid() in the backend code because it allows any SSSD user
to kill the complete sssd_be process.

If there is no other safe way to handle the credential cache I think the
related operations should be moved from the backend code to the
krb5_child.

bye,
Sumit

> 
> The last patch is an attempt to address ticket #2071,
> 
> It was necessary to add it here otherwise sssd will fail to operate
> correctly with some templates (as noted in #2071).
> However I am not sure that's the way we want to resolve the problem.
> The patch aimed at maintaining as much as possible a reasonable
> behavior, although the intended behavior was not really written
> anywhere. Personally I would rather scrap the patch and instead provide
> a new one that would simply stop creating public directories at all, I
> do not think it is sssd's role to fix/create directories that should be
> set up by the admin appropriately ahead of time (either manually of via
> tmpfiles.d or whatever).
> 
> I will try to follow up with a proposed patch that 'simplifies' sssd
> behavior instead of fixing it for #2071
> 
> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list