% cat mykrb5.conf
[libdefaults]
default_ccache_name = FILE:/my_ccache_location/krbcc_%{uid}
include /etc/krb5.conf
I cannot find a description of the behaviour of the ‘include’ directive with respect to this kind of thing.
If the system krb5.conf defines default_ccache_name, will my setting take precedence for my application when I set KRB5_CONFIG=/my_config_location/mykrb5.conf in its environment?
On Dec 12, 2022, at 3:24 PM, Greg Hudson <ghudson@MIT.EDU> wrote:
On 12/12/22 14:04, John Devitofranceschi wrote:
% cat mykrb5.conf
[libdefaults]
default_ccache_name = FILE:/my_ccache_location/krbcc_%{uid}
include /etc/krb5.conf
I cannot find a description of the behaviour of the ‘include’ directive with respect to this kind of thing.
https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#structure
is the documentation we have on the include directive. Your example should work.
In the profile model, a relation can have one or more values, with the order of values determined by the order of appearance. Some variables have a defined meaning for multiple values (like "kdc" in a realm section), but most variables, includingdefault_ccache_name, only have meaning for a single value.
Unfortunately, different parts of the code are not consistent in how they handle multiple values for a single-value variable. For variables handled through libkrb5, like default_ccache_name, the first value is used. So in your example, your default_ccache_name setting would take precedence over one defined in the system krb5.conf, because it was read first.
The profile library has the concept of marking a section or subsection
as "final", preventing further amendments to that section. But that
concept does not apply to individual relations (although it was
erroneously documented as applying to them prior to 1.17.1).
The profile library has the concept of marking a section or subsection
as "final", preventing further amendments to that section. But that >concept does not apply to individual relations (although it was
erroneously documented as applying to them prior to 1.17.1).
When I looked at the finalization support, I found that it had two
unexpected features:
1) The finalization support only works across files; in other words, if
you have KRB5_CONFIG=/etc/file1:/etc/file2, a finalized section in file1
suppresses the same section in file2. But it doesn't work if it's all
within file1.
2) An include statement in a krb5.conf file does NOT count as a new file for
the purposes of finalization.
If I am wrong about these things, I'd sure love a correction. Honestly,
I can't see a reason why a finalized section in a file just doesn't
suppress further sections, even within the same file.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 546 |
Nodes: | 16 (2 / 14) |
Uptime: | 03:10:52 |
Calls: | 10,386 |
Calls today: | 1 |
Files: | 14,057 |
Messages: | 6,416,595 |