[SSSD] [PATCH] Move ccache operations to krb5_child, allow the krb5_auth code to run unprivileged

Simo Sorce simo at redhat.com
Thu Nov 6 15:21:17 UTC 2014


On Wed, 5 Nov 2014 18:36:06 +0100
Jakub Hrozek <jhrozek at redhat.com> wrote:

> From 1afae1740eb9bf232c33dba77f643f88d0eeb7a3 Mon Sep 17 00:00:00 2001
> From: Jakub Hrozek <jhrozek at redhat.com>
> Date: Sat, 18 Oct 2014 22:03:13 +0200
> Subject: [PATCH 5/6] KRB5: Move all ccache operations to krb5_child.c
> 
> The credential cache operations must be now performed by the
> krb5_child completely, because the sssd_be process might be running
> as the sssd user who doesn't have access to the ccaches.
> 
> src/providers/krb5/krb5_ccache.c is still linked against libsss_krb5
> until we fix Kerberos ticket renewal as non-root.
> 
> Also includes a new error code that indicates that the back end should
> remove the old ccache attribute -- the child can't do that if it's
> running as the user.

I think I see an ordering issue but I am not completely sure
(unfortunately I am looking only at the patches because git am fails to
bring them on a copy of the master tree).

The main reason ccache handling was done in 2 parts is that in some
cases we need to do some preparatory work as root.
For example creating a user directory for DIR: ccache and similar.
I think this patches moves things around and causes all these functions
to be run after krb5_child has already dropped root in
k5c_setup() though. If that's the case as it looks to me I think this
patchset will not work as well as it should.

I also see that you added ERR_CREDS_EXPIRED_CCACHE to delete the ccache
once the reply is returned to the backend. But I am afraid deleting a
ccache may also require root privs as the ccache is owned by the user
but the sssd backend is running as the sssd user. Or am I missing
another change that addresses this ?

Also ERR_CREDS_EXPIRED_CCACHE seem not performing the same checks as
ERR_CREDS_EXPIRED, why (and why does it need to be different) ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list