[16924] in Kerberos-V5-bugs
[krbdev.mit.edu #9118] profile write operation interactions with
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Mon Apr 1 15:55:22 2024
From: "Greg Hudson via RT" <rt-comment@kerborg-prod-app-1.mit.edu>
In-Reply-To:
Message-ID: <rt-4.4.3-2-4029457-1712001315-885.9118-4-0@kerborg-prod-app-1.mit.edu>
To: "AdminCc of krbdev.mit.edu Ticket #9118":;
Date: Mon, 01 Apr 2024 15:55:15 -0400
MIME-Version: 1.0
Reply-To: rt-comment@kerborg-prod-app-1.mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
Mon Apr 01 15:55:15 2024: Request 9118 was acted upon.
Transaction: Ticket created by ghudson@mit.edu
Queue: krb5
Subject: profile write operation interactions with reloading
Owner: Nobody
Requestors: ghudson@mit.edu
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.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
