[krbdev.mit.edu #8651] kinit -kt KDB: Cannot find/read stored master key

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[krbdev.mit.edu #8651] kinit -kt KDB: Cannot find/read stored master key

Greg Hudson via RT-2
The profile library is designed to automatically pick up changes to
the profile each time a profile_get_* call is made.  This feature is
of dubious usefulness, because our code base is inconsistent about
how long it caches profile results for, but I've been reluctant to
simplify it out.

To do this, it calls stat() and compares the mtime to the mtime from
the previous stat() result.  It does compare fractional timestamps,
so you would think the double-read would happen all the time (since
stat() on /dev/fd/NN appears to just give the current time).  
However, there is also a guard against issuing too many stat() system
calls; at prof_file.c:316 we compare the current time to the last
time we read the filed or called stat(), and only issue a new stat()
call if the second has ticked over.

So I think in your scenario a failure only happens if the second
ticks over between the initial profile open and the profile read to
get the stash filename.

I think we could fix this scenario from our side by disabling the
stat-and-reread behavior for things that aren't regular files as
determined by S_ISREG().  From your side, you could of course work
around the issue by using a regular file.
_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|

Re: [krbdev.mit.edu #8651] kinit -kt KDB: Cannot find/read stored master key

Greg Hudson via RT-2
I already implementing the workaround to use a file-based config after discovering the double-read.
I think the test for S_ISREG seems appropriate (just don’t use lstat since you want to follow symlinks).


> On Mar 18, 2018, at 4:05 PM, Greg Hudson via RT <[hidden email]> wrote:
>
> The profile library is designed to automatically pick up changes to
> the profile each time a profile_get_* call is made.  This feature is
> of dubious usefulness, because our code base is inconsistent about
> how long it caches profile results for, but I've been reluctant to
> simplify it out.
>
> To do this, it calls stat() and compares the mtime to the mtime from
> the previous stat() result.  It does compare fractional timestamps,
> so you would think the double-read would happen all the time (since
> stat() on /dev/fd/NN appears to just give the current time).  
> However, there is also a guard against issuing too many stat() system
> calls; at prof_file.c:316 we compare the current time to the last
> time we read the filed or called stat(), and only issue a new stat()
> call if the second has ticked over.
>
> So I think in your scenario a failure only happens if the second
> ticks over between the initial profile open and the profile read to
> get the stash filename.
>
> I think we could fix this scenario from our side by disabling the
> stat-and-reread behavior for things that aren't regular files as
> determined by S_ISREG().  From your side, you could of course work
> around the issue by using a regular file.


_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs