A fork of the profile library code....
lxs at MIT.EDU
Thu Jan 5 16:20:38 EST 2006
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
> 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
> I'd worry about them as tag names, not section names. While Ted's
> 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.
Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
More information about the krbdev