kerberos and remote job scheduling/dispatching/perl fork()

[Matt Garman]

On Wed, Aug 22, 2012 at 10:07 AM, Booker Bense <bbense at gmail.com> wrote:
> On Fri, Aug 17, 2012 at 11:21 AM, Matt Garman <matthew.garman at gmail.com> wrote:
>> We have a simple, home-grown Perl-based job dispatching system.  It's
>> basically a per-user daemon that listens on a socket for job requests.
>>  When it gets a request, it calls fork() to dispatch the job.
>>
>> What we've found is that the fork()'ed jobs are getting "permission
>> denied" on NFSv4 mounts using krb5p security.  Before the fork,
>> though, permissions are OK.
>>
>> I wrote this simple Perl script to demonstrate the problem:
>
> I think your script error is just the result of the differences between
> ...
>
> In the first you have a tty and in the second you don't.

I agree, that or something else unrelated to Kerberos/nfs.

> Your real problem is the hinky way that nfsv4 matches kerberos
> credentials to processes. I haven't dinked around
> with NFSv4 a lot, but there is a deamon that more or less sits and
> watches for krb tgt files in /tmp and attempts
> to match them to the appropriate process when the local nfsd needs a
> users credentials.
>
> I think what you want is to investigate idmapd or rpcidmapd on your system.

It appears that the problem has to do with my sshd options.  In
particular, I had "GSSAPICleanupCredentials" set to yes (the default)
in /etc/ssh/sshd_config.  So I believe what happens is, after the
fork() call, my ssh session ends, and removes my /tmp/krb5cc* file.
Which leaves my forked process running, but now without a TGT, and
hence, no NFSv4.

Setting that sshd option to "no" and restarting sshd so far appears to
work.  I'm not sure if this is the "best" way to fix this, perhaps
idmapd and/or rpcidmapd offer a more elegant solution.  I'll have to
research those.

-Matt