Date: Fri, 21 Sep 2012 17:28:22 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: FreeBSD-Current <freebsd-current@freebsd.org> Cc: Herbert Poeckl <freebsdml@ist.tugraz.at> Subject: open-sshd uses non-default Kerberos cred cache breaking Kerberized NFS Message-ID: <627814917.1029105.1348262902010.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <505C1A99.4080800@ist.tugraz.at>
next in thread | previous in thread | raw e-mail | index | archive | help
Herbert emailed with a problem using the kerberized NFS client
in FreeBSD. He has been able to isolate the problem to the fact
that the sshd he uses (from open-sshd in ports) uses a non-default
tgt credentials cache.
The problem is that the gssd sets KRB5CCNAME to /tmp/krb5cc_<N>,
where <N> is the effective uid of the process doing the NFS RPC,
so that it can do an init_sec_context() GSSAPI call to get the
GSSAPI token. This fails if the tgt is in a credentials cache
file under a different name.
Here's the code snippet from gssd.c:
snprintf(ccname, sizeof(ccname), "FILE:/tmp/krb5cc_%d",
(int) argp->uid);
setenv("KRB5CCNAME", ccname, TRUE);
I can't think of any way to fix this, since the gssd runs as
effective uid==0 and needs to access the credentials cache for
other users.
Can anyone conversant with Kerberos suggest a fix?
Or does anyone know if there is an easy way to tell open-sshd
to use the default credential cache file name?
If not, all I can think of is to document this in gssd.8.
Thanks in advance for any help with this, rick
[Herbert Poeckl wrote in an email to me, copied with his permission]
> Hi Rick,
>
> On 09/20/2012 11:45 PM, Rick Macklem wrote:
> >>> Ok, after the mount, if you log in as a non-root user, kinit as
> >>> that
> >>> user to get a tgt, then try and access the mount point... "what
> >>> happens"?
> >>
> >> And then the request for root@IST.INTRA happens.
> >>
> > If you can capture packets from the mount until this happens and
> > email
> > it to me, hopefully I can spot when this happens. For example, try
> > something like:
> > # tcpdump -s 0 -w file.pcap host srv.ist.intra
> > - then in another window
> > # mount -t nfs -o nfsv4,gssname=host,sec=krb5 srv.ist.intra:/<path?>
> > /mnt
> > #
> > - then in a window logged into a non-root user that has kinit'd
> > % ls /mnt
> > - and whatever else it takes to cause it to access root@IST.INTRA,
> > which
> > shouldn't happen. (It should use the non-root user's principal or
> > the
> > host/soy.ist.intra@IST.INTRA one.)
> >
> > My guess is that some recent change has confused it so it tries to
> > use a
> > credential for uid 0.
>
> I did some more testing.
>
> This is what I found out:
>
> If the environment variable KRB5CCNAME for the user is not set, or is
> set to FILE:/tmp/krb5cc_20001 (user with uidnumber 20001) then
> everything works as expected!
>
> If the environment variable is set to something different, which
> happens
> when the user logs in with SSH, like FILE:/tmp/krb5cc_20001_HNYQhqGftu
> then I get the problem as described (request for root@IST.INTRA).
>
> Herbert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?627814917.1029105.1348262902010.JavaMail.root>