[15908] in Kerberos-V5-bugs
[krbdev.mit.edu #8651] profile library may try to reread from special
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Mon Mar 19 10:39:00 2018
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <rt-8651@krbdev.mit.edu>
Message-ID: <rt-8651-48311.14.3449134349611@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #8651'":;
Date: Mon, 19 Mar 2018 10:38:54 -0400 (EDT)
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
I think I was wrong about stat("/dev/fd/NN") returning the current
time as mtime for a pipe. I think to manifest this problem, kinit
has to initially open() and stat() the profile before printf has
finished writing to the pipe. (It will then block reading the data
from printf, but it already recorded the timestamp, and it doesn't
stat() again afterwards.) That's much less likely than the clock
second rolling over between profile_init and profile_get.
I was able to produce a failure using many repeated invocations of
KRB5_KDC_PROFILE=<(printf ...) kinit -k -t KDB:, but it took a long
time. To produce a failure in just one try, I wrote a simple test
program:
int
main(int argc, char **argv)
{
profile_t profile;
char *str;
if (profile_init_path(argv[1], &profile) != 0)
abort();
if (profile_get_string(profile, "a", "b", NULL, "no", &str) != 0)
abort();
printf("%s\n", str);
profile_release_string(str);
return 0;
}
and ran it with:
./a.out <(sleep 1; printf "[a]\nb=yes\n")
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
