[16144] in Kerberos_V5_Development
Re: Profile include support, round 2
daemon@ATHENA.MIT.EDU (ghudson@mit.edu)
Wed Aug 25 14:14:08 2010
Date: Wed, 25 Aug 2010 14:14:02 -0400 (EDT)
From: ghudson@mit.edu
Message-Id: <201008251814.o7PIE2Bq002733@outgoing.mit.edu>
To: krbdev@mit.edu
In-Reply-To: <ADD83D72-D253-4684-804B-7FCDE55C3AAE@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Ken wrote:
> Under "interface design" it says "line[s] from the file are parsed
> as if they belonged to the original profile file". [...] I'd label
> it good practice to always set the top-level section in the included
> file, and immediately after the include directive in the including
> file, to deal with these.
Although Ken didn't specifically ask for a change, I've decided that
it would be more conservative to ensure that include profile fragments
are syntactically independent of their parents.
My first thought was to reset the syntactic parsing state before and
after each include, but I thought of a simpler design: use a fresh
state for included files, sharing only the root section with the
parent. So if you do something pathological like:
krb5.conf:
[sec1]
var = {
a = 1
include /path/to/file
c = 3
}
/path/to/file:
[sec2]
b = 2
then the resulting profile relations would be:
sec1 -> var -> a = 1
sec1 -> var -> c = 3
sec2 -> b = 2
I don't expect anyone to do anything that pathological. But I could
see people doing something like:
[plugins]
includedir /etc/krb5/plugins
# plugin fragments just assume they're already in the [plugins]
and I don't really want us to have to support that.
Does this design revision sound okay? I will commit the change and
update the project proposal, but it's easily reverted if the dev
community prefers the preprocessor-like approach I began with.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
