[15907] in Kerberos-V5-bugs
Re: [krbdev.mit.edu #8651] kinit -kt KDB: Cannot find/read stored
daemon@ATHENA.MIT.EDU (Richard Basch via RT)
Sun Mar 18 16:46:48 2018
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Richard Basch via RT" <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <rt-8651@krbdev.mit.edu>
Message-ID: <rt-8651-48310.12.9970207441109@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #8651'":;
Date: Sun, 18 Mar 2018 16:46:33 -0400 (EDT)
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
Content-Type: multipart/mixed; boundary="===============2023196649897492528=="
Errors-To: krb5-bugs-bounces@mit.edu
--===============2023196649897492528==
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 <rt-comment@krbdev.mit.edu> 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.
--===============2023196649897492528==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
--===============2023196649897492528==--
