Turning off hostname canonicalisation

[Ken Hornstein]

>So I'd like to understand why folks are using [appdefaults].  Sun's  
>need is fairly straightforward: "we had it before and can't de- 
>support it".  But how are sites actually using this feature?

Fair enough.

Some background: we have a large number of users that are off-site (by
off-site, I mean that they use machines that aren't under our
administrative control); we package up Kerberos binaries and supply
them so they get access to our site (actually, a large bunch of DoD
sites, but that's not important).  I guess the real important part of
this is that we have a relatively large user population that uses
machines we don't control.  If we had administrative control of these
machines, maybe we'd do things differently.

The problem we ran into was that the users generally were not root on
these systems, and we wanted to provide them kits that didn't require
root access to install.  Any hard-coded path for application config
files we would give users would be wrong, and users didn't want to
copy a bunch of dotfiles to their home directory (in the interests of
simplicity, the Unix kit is just a tar file).  The users knew that they
had to deal with a config file already for the Kerberos library settings,
and they knew how to do that (with KRB5_CONFIG); the best solution I could
see was to simply glom onto this functionality.  I could have added
configuration file support to telnet/rlogin/rsh/ftp, but quite frankly
that would have been a lot of code for what I could only see would be
zero gain.  Now, you may point out that telnet and ftp have specific
configuration files.  I could have adapted those, but we would have had
the problem of delivering those config files to the right location,
and one config file is a lot easier to manage than 4 or 5.

Now of course on platforms like Windows and MacOS, you generally give
an installer and the OS already has an infrastructure in place to
handle application defaults.  We don't make use of the [appdefaults]
values on those platforms (except in the case of MacOS X programs which
are really ports of the Unix variants).

>* What tags to you use in the [appdefaults] section?  What values are  
>you setting them to?

>From what I've seen, we use the following tags:

- autologin	Does the same thing as "-a" for telnet
- forward	Does the same thing as "-f" for telnet/rlogin/rsh/ftp
- encrypt	Does the same thing as "-x" for telnet/rlogin/rsh (not ftp)
- forwardable	Sort-of schitzophrenic - Does the same thing as "-F" for
		telnet/rlogin/rsh/ftp, sets the "forwardable" flag for
		kinit/login.krb5 (although maybe I got rid of this
		functionality in lieu of the equivalant functionality
		in libdefaults)
- krb5_run_aklog	Tells kinit/telnetd/rlogind/rshd/ftpd/login.krb5
			whether or not to run aklog
- krb5_aklog_path	Path to aklog
- check_quota	Controls whether or not the "quota" command is run in login.krb5
- afs_retain_token	Controls whether or not "unlog" is run at logout
			time by telnetd/rlogind/rshd/ftpd

I admit, check_quota isn't exactly a Kerberos related knob.  But for
login.krb5, I didn't see a good place to put it (I suppose, in retrospect,
I should have simply done a configure option to disable it).

>* Do you need each application to receive different values for a  
>given tag?  If so, why?

In theory, yes.  In practice ... probably not so much.  One example
might be that in the case of background jobs, you would want to retain
the AFS token for interactive connections, but always delete them in
the ftp daemon (that's one case that we do use, but it's probably not
hugely important).  Another might be that you want the default to have
session encryption for interactive services, but not turn on encryption
in, say, ftp or rcp.  Right now we don't have code that does that (well,
maybe we do for rcp), but we could.  But I don't view it as critical.

>* Where does your code to read [appdefaults] live?  (In every  
>application?  In the Kerberos libraries?)

In every application (since they generally control application-level knobs,
not things that are under the domain of the Kerberos library).

>* What APIs do you use to read [appdefaults]?

I use the krb5_appdefault_* functions.

I have one rather large exception to this.  We have specialized code to
perform authorization checking.  This code runs on the application servers
and checks the value of the authtime field against the IP address of the
client connection.  The config file ends up looking like this:

[appdefaults]

	ftpd = {
		authtime = {
			1.2.3.4 = xxx
			3.4.5/24 = yyy
			default = zzz
		}
	
	authtime = {
		4.5.6.7 = xxx
		8.9/16 = yyy
		default = yyy
	}

AFAIK, none of the application servers have any sort of way to read a
config file at all.  Since these settings are generic to all of the
application servers at our site, it made sense to me to place the
values in krb5.conf.  In this case, there wasn't a good way to parse
out values like this in the existing API, so I created a new function
called krb5_appdefault_addrmatch(), in which you can pass in an IP
address and get back the best match from the entries in the config
file.  The library doesn't do anything with these values, other than
performing the parsing and matching; all of the authorization decisions
are made by code in each application server.  For this code, we
absolutely want to have the ability to have different applications have
different values (we use that feature today).  I'm only mentioning this
because, hey, you asked :-)

--Ken