A fork of the profile library code....

[Alexandra Ellwood]

On Jan 5, 2006, at 11:34 AM, Jeffrey Hutzelman wrote:

>
>
> On Thursday, January 05, 2006 10:10:54 AM -0500 Joseph Calzaretta
> <saltine at mit.edu> wrote:
>
>> The [appdefaults] section has tag names which are supposed to be
>> application names.  On Windows & Mac systems, at least, an
>> application name may contain a space.  I know Windows allows equal
>> signs in file names.  I don't know if it would actually end up
>> happening in practice where someone would want such a program in
>> their [appdefaults] section, but it's a possibility.
>
> Ahh, but tags in [appdefaults] are just that - tags.  They are not
> filenames, and an application shouldn't decide what tag to use (or  
> anything
> else) based on its own filename.  I don't think it's a serious  
> problem that
> tag names have a more limited namespace than do filenames.

So we want end users to edit these values by hand but we aren't going  
to use the application name as the tag for an application?

Using a space-free convention like Java names (eg:  
"com.example.ExampleApplication") as tag names is reasonable iff  
there's a GUI in between to help the user out.  But if these are hand- 
edited files then users will have to look up the tag name for every  
application they own.  The tag name should really be the thing they  
know ("Example Application"), not a string hidden in a resource or  
the application binary.

Note that I am not saying that a tag that identifies an application  
should be the application's file name.  That would also be a bad idea  
because operating systems may have hidden file extensions for  
executables (eg: on Mac OS X the file is "Example Application.app").   
The tag should be the name the user uses to identify the  
application.  And that name can definitely contain spaces.

Our config file could also benefit from tag synonyms like "ticket  
lifetime".  I've seen a bunch of '-' versus '_' mistakes that  
mystified users who couldn't understand why their libdefault edit  
didn't work.  And once I spent several hours debugging code only to  
discover that the code actually worked, and my test config file  
contained a similar typo.

(This is of course exactly the sort of problem which made me opposed  
to the design goal that these files being hand editable by end users  
in the first place.  However, since we're going to make them user  
editable, we should make the process of editing them user friendly.)


> If you're going to be concerned about special characters in realm  
> names,
> I'd worry about them as tag names, not section names.  While Ted's  
> parser
> may not currently handle it, it should be fairly easy to treat the []
> around a section name as quotes, though I think it would be a  
> mistake not
> to strip at least leading and trailing whitespace.  But tag names  
> have no
> natural quoting, and while not commonly used, there is a well- 
> defined class
> of realm names which must contain at least one equal.

The existing parser does this.  See the "[v4 realms]" and "[v4  
domain_realm]" in current config files on Mac OS X.


--lxs

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