[krbdev.mit.edu #9118] profile write operation interactions with reloading
"Greg Hudson via RT" <[email protected]> Mon, 01 Apr 2024 15:55:15 -0400
| Newsgroups | gmane.comp.encryption.kerberos.bugs |
|---|---|
| Message-ID | <rt-4.4.3-2-4029457-1712001315-885.9118-4-0@kerborg-prod-app-1.mit.edu> |
Mon Apr 01 15:55:15 2024: Request 9118 was acted upon. Transaction: Ticket created by [email protected] Queue: krb5 Subject: profile write operation interactions with reloading Owner: Nobody Requestors: [email protected] Status: open Ticket <URL: http://kerborg-prod-app-1.mit.edu/rt/Ticket/Display.html?id=9118 > The profile library stores parsed files in prf_data_t objects. Before each query to a prf_data_t object, the library checks (at most once per second) if the backing file's timestamp has changed. If so, the parsed relation tree is discarded and the file is reread. This reloading is suppressed for files marked NO_RELOAD (meaning the backing file is not a regular file), but not for files marked DIRTY due to a previous read/write setup. Therefore, any write operation could be discarded in favor of new data from the backing file. If the modification is being done to programmatically modify the backing file, this behavior can be written off as the profile library not having ACID semantics. But if the modifications are intended for profile_flush_to_file(), or krb5_init_context_profile() if profile_copy() is ever made to work with dirty profiles, then this behavior is unfriendly.