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:


#!/usr/bin/perl

use strict;

my $id = "PARENT";
my $childpid = fork();
if (0 == $childpid)
{
    $id = "CHILD";
    sleep(5);
}

print "\n--- $id ----\n";
print "    pid=$$\n";
print "    real_uid=" . getpwuid($<) . "\n";
print "    effective_uid=" . getpwuid($>) . "\n";

my $output = `/usr/kerberos/bin/klist -f`;
my $status = $? >> 8;
print "klist status=$status\n";
print "klist output:\n$output\n";
print "\n\n\n";


If I run that locally, I basically prints out a correct klist result
twice.  If I ssh into another server and run it, it also works.

But if I do something like this: "ssh other_server ./script.pl", then
the child klist prints nothing, and gives a different return code.

The weird thing is, though, if I change the klist to redirect to
stderr ("...klist -f 2>&1"), then it works!

Hopefully I'm just missing something simple...

Thanks again,
Matt
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to