On Sat, 5 Oct 2013 18:04:03 -0400
Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> On Fri, 4 Oct 2013 15:46:42 -0400 (EDT)
> Simo Sorce <ssorce@xxxxxxxxxx> wrote:
>
> >
> >
> > ----- Original Message -----
> > > The part of process_krb5_upcall that handles non-machine user creds
> > > first tries to query GSSAPI for credentials. If that fails, it then
> > > falls back to trawling through likely credcache locations to find them
> > > and then points $KRB5CCNAME at it before proceeding. There are a number
> > > of bugs in this code that this patch attempts to address.
> > >
> > > The code that queries GSSAPI for credentials does it as root and that
> > > almost universally fails to do anything useful unless we happen to be
> > > looking for non-machine root creds. Because of this, gssd almost always
> > > falls back to having to search for credcaches "manually" and then set
> > > $KRB5CCNAME if and when they are found. The code that handles credential
> > > switching is in create_auth_rpc_client, so it's too late to be of any
> > > use here.
> > >
> > > Worse yet, the GSSAPI code that handles finding credcaches does it based
> > > on the return from getuid(), so just switching the fsuid or even euid is
> > > insufficient. You must switch the real uid.
> >
> > In what case does it do this ?
> > If it is unconditional this is a bug in GSSAPI and we should fix it there.
> >
>
> As far as I can tell (primarily from stracing and experimenting) it
> always does this. Additionally it looks like KEYRING: support might
> also depend on this.
>
I took a closer look at this this morning and I think I see the
problem. The issue is in libkrb5 and the default definitions of the
credcache locations. For instance:
default_ccache_name = KEYRING:persistent:%{uid}
%{uid} expands to the real uid, not the effective one. If you change
that to:
default_ccache_name = KEYRING:persistent:%{euid}
...then it all works just by swapping the euid.
So, not a bug in libkrb5 or libgssapi per-se, but I think we're sort of
stuck with switching the real uid due to this.
The fact that the first patch in this series makes the daemon fork
before doing this should help mitigate any damage that an unprivileged
user can do.
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
