Profile include support, round 2

Ezra Peisach epeisach at MIT.EDU
Thu Aug 26 08:18:54 EDT 2010

  The biggest danger in my mind on allowing an include in the middle of 
a section is what happens if someone
forgets to close a brace before the include.  This could potentially be 
a support nightmare in that
people will not be able to tell where their definitions are going in 
this case...

I think a tool that reads in the profile and writes out a single file 
will be essential for people figuring out
how things work - and administrators - who want to make sure things look 
right (especially with includedir support)... And support desks who 
could then say - run this program and send me the results - which will 
list the
full profile in effect...


On 8/26/2010 2:29 AM, Danilo Almeida wrote:
> 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:
> nf
> 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 at

More information about the krbdev mailing list