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

Simo Sorce simo at redhat.com
Mon Nov 10 16:50:11 UTC 2014


On Mon, 10 Nov 2014 17:44:48 +0100
Jakub Hrozek <jhrozek at redhat.com> wrote:

> On Mon, Nov 10, 2014 at 11:37:41AM -0500, Simo Sorce wrote:
> > On Mon, 10 Nov 2014 17:12:55 +0100
> > Jakub Hrozek <jhrozek at redhat.com> wrote:
> > 
> > > On Thu, Nov 06, 2014 at 10:21:17AM -0500, Simo Sorce wrote:
> > > > 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 patches depended on the SELinux changes that were since
> > > merged to master. The attached patchset should apply on master
> > > cleanly.
> > > 
> > > > 
> > > > 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.
> > > 
> > > You're right, I admit I tested on RHEL and Fedora where we only
> > > use KEYRING: and FILE:/tmp/ where I didn't hit this issue. I was
> > > also confused by our removal of creating public ccache dir
> > > components -- now I realize we can still create user-owned
> > > directories under root-writably directories and
> > > DIR:/run/user/$UID is exactly this case.
> > > 
> > > This means we need to examine the ccache as root in order to
> > > determine whether to re-create it...with the attached patches the
> > > DIR cache seems to work fine.
> > > 
> > > > 
> > > > 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) ?
> > > 
> > > No, the ERR_CREDS_EXPIRED_CCACHE semantics is different. The
> > > krb5_child is able to remove the old ccache from disk or from the
> > > kernel keyring, but in case the child dropped privileges to the
> > > user who is logging in, it cannot delete the ccache attribute from
> > > sysdb..so ERR_CREDS_EXPIRED_CCACHE is a way of telling sssd_be to
> > > remove this attribute istead.
> > 
> > What happen if sssd_be is running unprivileged itself ?
> 
> sssd_be is running as the sssd user who has rw access to the cache:
> ll /var/lib/sss/db/cache_ipa.example.com.ldb 
> -rw-------. 1 sssd sssd 1609728 Nov 10
> 17:18 /var/lib/sss/db/cache_ipa.example.com.ldb

Wait, isn't this about user's ccaches ?

If the cache is owned by sssd, in what case the krb5_child helper
would not be able to deal with it ?

> > > Thank you for the review. New patches are attached (and I just
> > > realized I didn't CC you in my reply to your other mail; sorry)
> > 
> > NP: I'll try to catch up on the replies and look at the new patches
> > in the afternoon.
> > 
> > Simo.
> > 
> > -- 
> > Simo Sorce * Red Hat, Inc * New York



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



More information about the sssd-devel mailing list