[16160] in Kerberos_V5_Development
RE: Profile include support, round 2
daemon@ATHENA.MIT.EDU (Danilo Almeida)
Thu Aug 26 02:30:05 2010
From: "Danilo Almeida" <dalmeida@mit.edu>
To: <ghudson@mit.edu>, <krbdev@mit.edu>
In-Reply-To: <201008251814.o7PIE2Bq002733@outgoing.mit.edu>
Date: Wed, 25 Aug 2010 23:29:49 -0700
Message-ID: <002b01cb44e8$19ee7330$4dcb5990$@edu>
MIME-Version: 1.0
Content-Language: en-us
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Greg wrote:
> 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 am not convinced that allowing an include in the middle of parsing a
section is a good idea. It mean potentially supporting an odd-looking
syntax w/o any benefit. Or is there some scenario where such a syntax is
actually useful?
If we do want to disallow the above: From my understanding of the profile
format, relations must be inside a section. So it seems like it would be
relatively straightforward to require that the next thing after an include
is a new section and not another relation...and that you are not inside a
relation when processing an include.
References:
http://web.mit.edu/~kerberos/krb5-1.8/krb5-1.8.3/doc/krb5-admin.html#krb5.co
nf
http://docs.sun.com/app/docs/doc/816-5174/krb5.conf-4?a=view
Btw, what are the restrictions on the name of a relation? Is it any
sequence of non-space characters? i.e., is the following allowed:
[sec1]
a b = something
Thanks,
- Danilo
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
