(Final?) krb5.Conf Lexer/Parser Proposal

[Alexandra Ellwood]

On Jan 6, 2006, at 2:26 PM, Theodore Ts'o wrote:

> On Thu, Jan 05, 2006 at 07:17:44PM -0500, Alexandra Ellwood wrote:
>> And if you want to change large portions of the system config file,
>> you can just copy, edit and use the KRB5_CONFIG environment variable
>> to override it completely.  This is even possible on Mac OS X via
>> ~/.MacOSX/environment.plist, which affects all applications,
>> including GUI ones.
>
> But this argument could just as easily be used to say that config file
> chaining shouldn't be supported at all, since you can always do the
> copy, modify, and repoint KRB5_CONFIG environment variable approach...
>
> And from a support point of view, only supporting a single config file
> would certainly be easier on the help desks than allowing multiple
> config files.

Supporting a single config file would definitely be easier.  However  
there is an obvious common case where users have a personal service  
(their bank, credit card company, etc) which uses Kerberos and would  
like to access it from machines at another Kerberos-using site.   
There's no way we can expect site administrators to maintain realm  
and domain-realm mapping information for all possible companies which  
users might interact with.  At large universities such config files  
would get outrageously long and would be difficult to keep up to  
date.  Sane site administrators would say no to such requests outright.

We need some way for the user to maintain their own personal realm  
and domain-realm information.

In addition if we start using appdefaults again, I can definitely see  
users wanting to use personal config files to override the site  
preferences for various applications.  Users have a legitimate  
expectation to get their own application preferences.  (Not that I  
think appdefaults are a good idea, but there seems to be some desire  
for them in the Kerberos community.)


>> So what exactly does the final signifier gain us?
>>
>> Now maybe I'm missing something obvious, but the only case I can
>> think of where you would want to use the final signifier is if you
>> want to *replace* an entire sub-section or a multi-value tag such as
>> the KDC tags for a single realm.
>
> The other reason why you might want to do something like this is if
> the *presence* of a particular config setting has a specific meaning,
> and you want to (for example) mask the presence of a particular
> setting in the global config file.  This could be considered a special
> case of the *replacing* an entire section, but it's important to call
> this out in the general case, I think.
>
> (You could argue that designing profile configuration variables that
> worked this way is a really bad idea, and I'd probably even agree with
> you....)

I believe so far we've avoided this.  All possible values for a tag  
should be representable with a tag value.  For example, our boolean  
valued tags support no/off/false/0 as negative tag values to turn off  
settings in addition to the positive yes/on/true/1.  This is  
intentional and (as you mention above) a good idea.


>> Even with the final signifier it's not like we'd be supporting
>> everything the user would like to do.  The user might like to add a
>> tag to the end of a list of multi-valued tags.  Since the user's tags
>> always come first in the merged configuration, this is impossible
>> without replacing the entire section in the user's config file or
>> using KRB5_CONFIG.
>
> Yes, but with the final signifier there is at last a way you can do it
> by replacing the entire section in the user's config file:
>
> [realms]
> 	ATHENA.MIT.EDU = {
> 		kdc = kerberos-2.mit.edu:88
> 		kdc = kerberos.mit.edu:88
> 		admin_server = kerberos2.mit.edu
> 	}*
>
> Witout the final signifier, the only thing you can do is to copy the
> global config file and repoint KRB5_CONFIG.

True, but the only reason you'd want to do this is if the existing  
ATHENA.MIT.EDU description in the system configuration file contains  
invalid information.  And if it's invalid then you have legitimate  
cause to complain to your sysadmin to fix it.

On the other hand I imagine that you wouldn't have legitimate cause  
to ask your sysadmin to add realm configurations which only you use  
to the system configuration.  At a site with hundreds of thousands of  
users supporting that sort of request could easily become infeasible.

Thus my argument is that multiple config files without the final  
signifier are useful, and aren't made particularly more useful with  
the addition of the final signifier.


The only reason I can see why my argument would be flawed is if there  
is some tag in a section configuration that could make the section  
valid for one user and invalid for another.  If such a tag existed it  
might be necessary for a small number of users to override a valid  
section.  Note that this tag would have to be a multi-valued tag  
(like "kdc") because single-value tags can already be overridden  
without using the final signifier.

Can anyone think of such a tag?  Would we even want to create such a  
tag?  It seems to me that even the existence of a tag like that would  
be a bad idea since it would create an easy way for sysadmins to  
cause problems for their sites.


>> I'm also concerned about the support issues of having a final
>> signifier.  The syntax seems sufficiently subtle that site help desks
>> would have trouble debugging busted configurations.  Users are
>> already in the habit of cut and pasting config file lines from random
>> locations and not even bothering to check if the lines do anything
>> (eg: "ticket_lifetime = 600").  Imagine the nightmare support calls
>> which could result from accidentally copying lines containing a '*'.
>
> As I mentioned earlier, I would think this would be an argument for
> not supporting chained configuration files at all.

Support folks for the Mac are already used to asking for the user's  
config files in three different locations, and at least so far users  
have been good about returning all the files.  And yes, several times  
we've gotten more than one file back in an Apple bug report with a  
user config file adding the realm that causes the failure and setting  
default_realm to it.


> Although thinking about this some more, if someone cuts and pastes a
> complete section replacement, complete with the trailing '*', it's
> hard to see how this would likely cause a "nightmare support call".

Well let's say we have a site with multiple locations in different  
countries, each of which has a slave KDC.  If a user accidentally  
used the '*' operator to override the site realm section with one  
lacking the KDC closest to them, it could cause Kerberos to become  
"slow" despite the fact that the proximal KDC is still in the site  
config file.  And depending on how fast the ticket gets escalated up  
the support chain it might take a while before anyone realized that  
the closest KDC wasn't even being contacted.

Obviously that's a contrived example.  My real point is that the  
final signifier '*' syntax is difficult to see in a large config file  
and difficult to figure out what it does.  If we decide we want to  
preserve the final signifier mechanism I would argue we need a more  
noticeable and self-descriptive syntax for it.  The current syntax is  
more appropriate for a machine-generated config file with a GUI front- 
end that displays what is going on in a clear and obvious manner.

About half the people on the *MIT Kerberos team* didn't even remember  
what the syntax did until we read the profile code and the  
Administrator's Guide.  To make matters worse, past experiences  
suggest that our users often copy and paste lines into their config  
files without understanding what they do, so we can't even expect  
them to know that they added a '*' in the first place.


--lxs

Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>