[16928] in Kerberos-V5-bugs
[krbdev.mit.edu #9117] profile write operation interactions with
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Fri Apr 12 14:42:57 2024
From: "Greg Hudson via RT" <rt@kerborg-prod-app-1.mit.edu>
In-Reply-To: <rt-4.4.3-2-1528752-1712936755-1335.9117-5-0@kerborg-prod-app-1.mit.edu>
Message-ID: <rt-4.4.3-2-1528742-1712947370-1661.9117-5-0@kerborg-prod-app-1.mit.edu>
To: "AdminCc of krbdev.mit.edu Ticket #9117":;
Date: Fri, 12 Apr 2024 14:42:50 -0400
MIME-Version: 1.0
Reply-To: rt@kerborg-prod-app-1.mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
<URL: http://kerborg-prod-app-1.mit.edu/rt/Ticket/Display.html?id=9117 >
profile include directives are handled at parse time, so the profile library's
representation of a Fedora /etc/krb5.conf file is a single tree. The concerns
in this ticket only apply if you do something like KRB5_CONFIG=$HOME/
krb5.conf:/etc/krb.conf so that the profile object contains two separate
trees.
Unfortunately, we are not historically consistent about how to handle multiple
assignments to a single-valued relation. libkrb5 uses the first value, while
libkadm5 uses the last one (presumably following the reasoning you gave about
users' intuitions around variable assignment). Changing either behavior to
match the other risks breaking existing configurations. In hindsight, I think
this is a good argument against using repeated assignments to represent lists
in a configuration language, but we can't do much about that now.
It is true that beefing up final-flag support would give FreeRDP a way to do
what it wants without the profile write APIs, and to handle similar use cases
around modifying the default configuration. Perhaps that is a good variant of
the null solution: document that modifying the default profile is discouraged,
and instead encourage prepending an override tree to the default
configuration. I think we might need to provide an additional API to make
that easy, as simply including /etc/krb5.conf would not be correct for all
process environments. One concern for this direction is that applications
would be relying on all-new functionality, whereas the current FreeRDP
approach *almost* works with existing krb5.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
