How krb5.conf is parsed (especially in respect to comments)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

How krb5.conf is parsed (especially in respect to comments)

Harald Barth-2

Is there any consenus about using comments in krb5.conf and how it
should be parsed?

I have tried to figure out what is OK according to the documentation
but not found anything about comments in the manual pages. There
is a widespread use of comments like this:

[libdefaults]
        default_realm = EXAMPLE.COM
# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms

and usage of "#" at the beginning of the line will make the parser
ignore that line and it works as a comment.

But if I write:

[libdefaults]
        renew_lifetime = 3d # this comment will break things

this will make that this line will not parse and ignored.
Probably not what a normal user expects, especially as
kinit does not even warn about it.

Ok, a "power user" may discover verify_krb5_conf and run that command:

$ verify_krb5_conf
(...)
verify_krb5_conf: /libdefaults/renew_lifetime: failed to parse "3d # this comment will break things" as time
(...)

it tells me that problem. But then on would expect that
verify_krb5_conf would have the same logic as kinit when telling me
what is good or bad but i has not. Looks at these examples:

Entry in krb5.conf
     renew_lifetime = 3d
verify_krb5_conf
     OK
kinit
     consistent with above (does parse and get renewable for 3 days)


Entry in krb5.conf
     renew_lifetime = 3 0
verify_krb5_conf
     verify_krb5_conf: /libdefaults/renew_lifetime: failed to parse "3 0" as time
kinit
     consistent with above (does not parse and tickets are not renewable)

Entry in krb5.conf
     renew_lifetime = 3 d
verify_krb5_conf
     OK (no complaint)
kinit
     not consistent with above (does not parse and tickets are not renewable)

Entry in krb5.conf
     renew_lifetime = 3 days
verify_krb5_conf
     OK (no complaint)
kinit
     not consistent with above (does not parse and tickets are not renewable)


So there are several things that should be fixed to get the "least
astonoishment" on part of the user:

* Usage of comments in the file format should be documented

* Usage of # to comment rest of line would probably appreciated by most users

* kinit should warn if parts of relevant values of its options can not
  be parsed properly

* The parser of kinit and verify_krb5_conf should agree if a time
  string can be parsed or not, especially if whitespace should end
  parsing of a time or not. Even the manual page does disagee with
  itself on that matter:

     STRINGs consists of one or more non-whitespace characters.

and 5 rows below:

      time
          values can be a list of year, month, day, hour, min, second.  Example: 1 month 2 days 30 min.

Test were made with heimdal version 7.4.0

Of course it would be nice if this would not differ too much among the
kerberos impementations.

Harald.
Reply | Threaded
Open this post in threaded view
|

Re: How krb5.conf is parsed (especially in respect to comments)

Jeffrey Altman-2
On 3/26/2018 5:29 AM, Harald Barth wrote:
>
> Is there any consenus about using comments in krb5.conf and how it
> should be parsed?

yes.

> I have tried to figure out what is OK according to the documentation
> but not found anything about comments in the manual pages. There
> is a widespread use of comments like this:
>
> [libdefaults]
> default_realm = EXAMPLE.COM
> # The following krb5.conf variables are only for MIT Kerberos.
> krb4_config = /etc/krb.conf
> krb4_realms = /etc/krb.realms
>
> and usage of "#" at the beginning of the line will make the parser
> ignore that line and it works as a comment.
The above is a comment.

> But if I write:
>
> [libdefaults]
> renew_lifetime = 3d # this comment will break things

This is not a comment.  This is setting the value of "renew_lifetime" to
the string "3d # this comment will break things".   The error that is
generated is the failure of

  "3d # this comment will break things"

to be a valid date string.

It is perfectly valid for a '#' to be present in a value string.  A
value string is all of the contents to the right of the equal sign until
the end of line.




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How krb5.conf is parsed (especially in respect to comments)

Harald Barth-2

>> # The following krb5.conf variables are only for MIT Kerberos.

> The above is a comment.

I have not found a place describing this, but I did not serach too
long.

> It is perfectly valid for a '#' to be present in a value string.

> A value string is all of the contents to the right of the equal sign
> until the end of line.

To the right of the equal sign and any following whitespace. So it
seems one can have whitespace inside the value but no value which
starts with whitespace. According to my tests these two values are the
file "/tmp/foo bar #"

        default_cc_name =      /tmp/foo bar #baz
or
        default_cc_name =/tmp/foo bar #baz

give
$ klist
klist: No ticket file: /tmp/foo bar #baz

So that probably means that both

>  STRINGs consists of one or more non-whitespace characters.

from Heimdal man krb5.conf and kinits handing of

        renew_lifetime = 3 days

are wrong?

Probably the documentation, kinit and verify_krb5_conf should agree
about the format.

Harald.
Reply | Threaded
Open this post in threaded view
|

Re: How krb5.conf is parsed (especially in respect to comments)

Nico Williams
On Mon, Mar 26, 2018 at 09:26:11PM +0200, Harald Barth wrote:

> > A value string is all of the contents to the right of the equal sign
> > until the end of line.
>
> To the right of the equal sign and any following whitespace. So it
> seems one can have whitespace inside the value but no value which
> starts with whitespace. According to my tests these two values are the
> file "/tmp/foo bar #"
>
> default_cc_name =      /tmp/foo bar #baz
> or
> default_cc_name =/tmp/foo bar #baz
>
> give
> $ klist
> klist: No ticket file: /tmp/foo bar #baz

Yes.

> So that probably means that both
>
> >  STRINGs consists of one or more non-whitespace characters.
>
> from Heimdal man krb5.conf and kinits handing of
>
> renew_lifetime = 3 days
>
> are wrong?

No, the docs are wrong.  This depends, among other things, on whether a
parameter is treated as sinle- or multi-valued.  This mess is really
some grad student's fault in MIT Kerberos in the 90s, if not even
earlier.

We should check that we have the same behavior as MIT.

We should really move to a new format some day...  But that will
probably never happen.

> Probably the documentation, kinit and verify_krb5_conf should agree
> about the format.

Probably :/

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: How krb5.conf is parsed (especially in respect to comments)

Harald Barth-2

> No, the docs are wrong.

OK.

I found that "renew_lifetime = 3 days" actually works but
"renew_lifetime = 3 days " does not. Difficult to see.

So I think in parse_something() this fixes it:

$ diff -u parse_units.c{.orig,}
--- parse_units.c.orig  2017-07-11 07:14:16.000000000 +0200
+++ parse_units.c       2018-03-27 00:44:20.800540496 +0200
@@ -135,6 +135,8 @@
        }
        if (*p == 's')
            ++p;
+       while(isspace((unsigned char)*p))
+           ++p;
     }
     return res;
 }


>> Probably the documentation, kinit and verify_krb5_conf should agree
>> about the format.

verify_krb5_conf seems to strip trailing space before giving it to parse_time()

This in config_file.c:parse_binding() looks suspicious:

        while(p > p1 && isspace((unsigned char)*(p-1)))
            --p;

Harald.