[1900] in Kerberos-V5-bugs
Review of install.texi
daemon@ATHENA.MIT.EDU (John Hawkinson)
Sun Apr 21 05:10:30 1996
Date: Sun, 21 Apr 1996 05:10:26 -0400
To: krb5-bugs@MIT.EDU
From: John Hawkinson <jhawk@MIT.EDU>
I just went through install.texi, and did node-by-node comments.
Some of them are a bit picky/pedantic, but some of them are real.
Have fun.
--jhawk
> File: install, Node: Introduction, Next: How Kerberos Works, Prev: Top, Up: Top
>
> find portability problems when you try to build Kerberos V5 on a
> platform on which the developers have not used. Please send bug reports
and platforms they DID used. remove phrase...
> File: install, Node: How Kerberos Works, Next: Building Kerberos, Prev: Introduction, Up: Top
>
> of details; for more information, see Kerberos: An Authentication
> Service for Open Network Systems, a paper presented at Winter USENIX
> 1988, in Dallas, Texas.
cite!
> File: install, Node: The User-Kerberos Interaction, Prev: Network Services and the Master Database, Up: How Kerberos Works
> are allowed to login to `laughter' (because the your name
> matches one in /etc/passwd, or you are in the appropriate
> `.klogin' or `.k5login' file), will let you login.
Remove .klogin reference.
> File: install, Node: Building with Separate Build Directories, Next: Building using lndir, Prev: Building Within a Single Tree, Up: Doing the Build
>
> `make' program support `VPATH'. GNU's gmake will provide this
GNU make is GNU make. It's not "gmake".
> File: install, Node: Building using lndir, Prev: Building with Separate Build Directories, Up: Doing the Build
Note that this differs from the lndir distributed and installed with X11R6.
> File: install, Node: The DejaGnu Tests, Prev: Testing the Build, Up: Testing the Build
> (1) If you are fortunate enough to have a previous version of
> Kerberos V5 or V4 installed, and the Kerberos rlogin is first in your
> path, you can setup `.k5login' or `.klogin' as appropriate to allow you
> access.
Needs "respectively".
> File: install, Node: Options to Configure, Next: osconf.h, Prev: Testing the Build, Up: Building Kerberos
>
> Options to Configure
> ====================
>
> There are a number of options to `configure' which you can use to
> control how the Kerberos distribution is built. The following table
> lists the most commonly used options to Kerberos V5's `configure'
> program.
Should either explicitly list --help in the list of options, or state that
the complete list can be obtained with "./configure --help".
> `--enable-athena'
> Was used to setup configuration files in such a way as to be
> compatible with the Athena environment at MIT. It currently does
> not appear to do anything useful.
Bzzt. Not a commonly used option.
> `--with-kdc-kdb-update'
> Set this option if you want to allow the KDC to modify the Kerberos
> database; this allows the last request information to be updated,
> as well as the failure count information. Note that this doesn't
> work if you're using slave servers!!! It also causes the database
> to be modified (and thus needing to be locked) frequently.
Please note that the implementors do not test using this (unless that
is no longer true).
> % configure --with-cc=suncc --with-ccopts=-O
Bad dog. Please use "./configure" as the example.
Consider documenting --with-kdb-db.
> File: install, Node: osconf.h, Next: Shared Library Support, Prev: Options to Configure, Up: Building Kerberos
Seems annoying that we don't document the default values
of these options.
> `RCTMPDIR'
> The directory which stores replay caches.
Should include a comment about the writability and/or stickyness of
the directory.
> File: install, Node: Shared Library Support, Next: OS Incompatibilities, Prev: osconf.h, Up: Building Kerberos
> libraries. In all cases, executables linked with the shared libraries in
> this build process will have built in the location of the libraries,
> therefore obliterating the need for special LD_LIBRARY_PATH environment
s/LD_LIBARY_PATH/&, et al/
> Currently the supported platforms are: NetBSD 1.0A, AIX 3.2.5, AIX
> 4.1, Solaris 5.3, Alpha OSF/1 >= 2.1, HP-UX >= 9.X.
NetBSD 1.1
Solaris >= 5.3 ??
> File: install, Node: Shared Library Theory, Next: NetBSD Shared Library Support, Prev: Shared Library Support, Up: Shared Library Support
> (2) Both are necessary sometimes as the shared libraries are
> dependent on other shared libraries
Not a complete sentence. End with a period.
> File: install, Node: NetBSD Shared Library Support, Next: AIX Shared Library Support, Prev: Shared Library Theory, Up: Shared Library Support
> Shared library support has been tested under NetBSD 1.0A using GCC
> 2.4.5. Due to the vagaries of the loader in the operating system, the
NetBSD 1.1B
> File: install, Node: AIX Shared Library Support, Next: Solaris 5.3 Shared Library Support, Prev: NetBSD Shared Library Support, Up: Shared Library Support
>
> AIX Shared Library Support
> ---------------------------
Two spaces after AIX.
> provided.Therefore, supporting multiple versions of the Kerberos shared
Need space after "provided."
> File: install, Node: Alpha OSF/1 Shared Library Support, Prev: Solaris 5.3 Shared Library Support, Up: Shared Library Support
Consider replacing all references to Alpha OSF/1 with Digital Unix.
> The one disadvantage with the method we are using
This node ends here. Kind of a cliffhanger. The phrase "The one disadvangage"
is used in two consecutive paragraphs. This is silly, aside from making
searching for that string a pain. Reword that paragraph and the preceding.
> File: install, Node: OS Incompatibilities, Next: Using Autoconf, Prev: Shared Library Support, Up: Building Kerberos
> * Ultrix 4.2/3::
> * Alpha OSF/1 V1.3::
> * Alpha OSF/1 V2.0++::
> * BSDI::
> * Solaris versions 2.0 through 2.3::
> * Solaris 2.X::
> * SGI Irix 5.X::
Consider grouping OSF/1 nodes and Solaris nodes. Certainly overlapping
OS versions should be in a common subnode. (you know what I mean)
> File: install, Node: Ultrix 4.2/3, Next: Alpha OSF/1 V1.3, Prev: OS Incompatibilities, Up: OS Incompatibilities
>
> Ultrix 4.2/3
> ------------
>
> On the MIPS platform, using the native compiler, `md4.c' and `md5.c'
The "MIPS platorm"? I'll see you on my cisco 4700.
> Using GCC version 2.5 instead of the native compiler will also work
"2.5 or later", or remove version specification.
> File: install, Node: Alpha OSF/1 V1.3, Next: Alpha OSF/1 V2.0++, Prev: Ultrix 4.2/3, Up: OS Incompatibilities
> There is a bug in OSF/1's fgrep which causes the `configure' script
> to fail.
configure should never fail. Fix the configure script to not call
fgrep or to detect the fgrep failure and yell.
See above comment about 2.5 for 2.6.3 reference.
> File: install, Node: Alpha OSF/1 V2.0++, Next: BSDI, Prev: Alpha OSF/1 V1.3, Up: OS Incompatibilities
> There formerly used to be a bug when using the native compiler in
> compiling `md4.c' when compiled without either the `-O' or `-g'
"There used to be" or "There was formerly". Not both.
> compiler options. (This could possibly be the same sort of bug as
> found in *Note Ultrix 4.2/3::, but that seems rather remarkable.) We
The parenthetical note does not make sense. Please reword.
> File: install, Node: BSDI, Next: Solaris versions 2.0 through 2.3, Prev: Alpha OSF/1 V2.0++, Up: OS Incompatibilities
> BSDI versions 1.0 and 1.1 reportedly has a bad `sed' which causes it
> to go into an infinite loop during the build. The work around is to
Check this in configure!
> File: install, Node: Solaris versions 2.0 through 2.3, Next: Solaris 2.X, Prev: BSDI, Up: OS Incompatibilities
> Workarounds:
>
> 1. Supply your own resolver library.
Such as bind-4.9.3pl1 available from ftp.vix.com.
> 3. Make sure your /etc/nsswitch.conf has the line:
>
> hosts: files dns
"Make sure your /etc/nsswitch.conf has `files' before `dns' like:" or
suchlike. Don't confuse poor people stuck with other methods (eg:
NIS).
Note that making this change may cause other programs in your environment
to break (or at least behave differently). Eit.
> File: install, Node: Solaris 2.X, Next: SGI Irix 5.X, Prev: Solaris versions 2.0 through 2.3, Up: OS Incompatibilities
> LD_LIBRARY_PATH environment variable when you compile it. Alternatively
> you can use the `-i' option to `cc', by using the specifying
> `--with-ccopts=-i' option to `configure'.
Huh? What's `cc'? Solaris doesn't ship with a native C compiler.
> File: install, Node: SGI Irix 5.X, Prev: Solaris 2.X, Up: OS Incompatibilities
> If you are building in a tree separate from the source tree, the
> vendors version of make does not work properly with regards to `VPATH'.
> It also has problems with standard inference rules in 5.2 (not tested
> yet in 5.3) so one needs to use GNU's make.
Check this in configure!
> Under 5.2, there is a bug in the optional System V `-lsocket'
> library in which the routine `gethostbyname()' is broken. The system
> supplied version in `-lc' appears to work though so one may simply
> specify `--with-netlib' option to `configure'.
>
> In 5.3, `gethostbyname()' is no longer present in `-lsocket' and is
> no longer an issue.
Insert broken record statement.
> File: install, Node: Picking a Realm Name, Next: Configuration files, Prev: Installation on any Machine, Up: Installation on any Machine
Consider noting that "Changing realm names is hard. Get it right the
first time."
> File: install, Node: krb5.conf, Next: Converting V4 configuration files, Prev: Configuration files, Up: Configuration files
> The `krb5.conf' uses an INI-style format. Sections are delimited by
Damn, is *that* why it was familiar. How...lame.
> Create a `/etc/krb5.conf' file using the following format:
Oh, the irony. Not all systems use /etc/krb5.conf :-(. (Also
ocurrs in node "Required Programs".)
> In many situations, the default realm in which a host operates will
> be identical to its Internet domain name, with the first component
> removed and all letters capitalized. For example, `ftp.cygnus.com' is
Reference node "Picking a Realm Name".
> realm name. This is accomplished with the `[domain_realm]' stanza
This line wants terminal punctuation.
> Each line of the translation file specifies either a host name or
> domain name, and its associated realm:
This sentence seems dain bramaged. A host name _is_ a domain name
(we hope). Someone should rewrite this in good DNS-speak, whatever that
is (?).
> For example, to map all hosts in the domain LSC.MIT.EDU to
> LCS.MIT.EDU but the host FILMS.LSC.MIT.EDU to MIT.EDU your file would
> read:
> [domain_realm]
> .LSC.MIT.EDU = LSC.MIT.EDU
> FILMS.LSC.MIT.EDU = MIT.EDU
s/LCS/LSC/. Be careful here!
This section should specify how subdomains of domains work, and
whether first or last gets precedence.
> See the `[SOURCE_DIR]/config-files/krb5.conf' file for an example
Have we been using the convention [SOURCE_DIR] throughout this
document? I hadn't noticed.
> File: install, Node: Converting V4 configuration files, Next: /etc/services, Prev: krb5.conf, Up: Configuration files
> longer used by the V5 library. A Perl script has been provided to allow
s/Perl/@sc{PERL}/
(as marc reminds us, perl is an acronym)
> File: install, Node: /etc/services, Prev: Converting V4 configuration files, Up: Configuration files
> All hosts which will use Kerberos will need to have certain ports
> defined in the system's `/etc/services' file. The file
> `[SOURCEDIR]/config-files/services.append' contains the entries which
> should be appended to the `/etc/services' file.
I seem to be getting more and more picky. Sorry. This implies all the
entries in the file are necessary for proper operation, which isn't
quite so. Particularly when clients fall back (they still do, right?).
> File: install, Node: Required Programs, Prev: Configuration files, Up: Installation on any Machine
> * `[K_USER]/kinit' -- This program allows you to obtain Kerberos
> credentials.
>
> * `[K_USER]/bin/kdestroy' -- This program allows you to destroy
> Kerberos credentials which are no longer needed.
>
> * `[K_USER]/klist' --- This program allows you to list the
> credentials found in your credentials cache.
kdestroy doesn't need a bin/ before it. "Required" != "should be
installed" ==> Discrepancy.
> File: install, Node: Initializing the KDB, Next: Storing the Master Password, Prev: kdc.conf, Up
> Login to the Kerberos KDC, and use the `su' command to become root.
Don't you hate "Don't login as root -- use su" on systems with fascist
su where you're not in group wheel? Nix petty political comments.
> The `kdb5_create' command creates and initializes the master
> database. It asks you to the database's master password. Do not
> forget this password. If you do, the database becomes useless. (Your
> realm name should be substituted for [REALMNAME] below.)
Seems inconsistent with the concept of stashing. I recommend rewriting
this node and the next to eliminate such fallacies.
> File: install, Node: Storing the Master Password, Next: Adding Users to the Database, Prev: Initializing the KDB, Up: Installing the KDC
> s compromised. (If this happens you all of your user's passwords must
> be set to new values manually -- i.e., not using Kerberos.) The master
"If this happens you"?
Note that this paragraph provides the implication that it is
acceptable to use Kerberos to change passwords that were
compromised by other means. This is a dangerous assumption.
When kadmind is stable, I will look at implementing my proxy
passwd-changing hack. I said that months ago, but kadmind has not been
stable.
> File: install, Node: Adding Users to the Database, Next: Starting the Kerberos Server, Prev: Storing the Master Password, Up: Installing the KDC
> The `kdb5_edit' program is used to add new users and services to the
>master database, and to modify existing database information.
s/is used/may be used/
kdb5_edit should not be used as part of normal operations. Refer users
to the admin server...
> File: install, Node: Setting up Slave Kerberos Servers, Next: Inter-realm Kerberos Operation, Prev: Starting the Kerberos Server, Up: Installing the KDC
This node or a subnode should mention using slave servers for
load sharing (i.e. it doesn't really work).
> File: install, Node: Kerberos Slave Database Propagation, Next: Installing a Slave Server, Prev: Setting up Slave Kerberos Servers, Up: Setting up Slave Kerberos Servers
> On the slave server, the `kpropd' program is invoked out of
> `/etc/inetd' server. After `kprop' and `kpropd' have mutually
"/etc/inetd"? Not on my OS...
> File: install, Node: The Administration Server, Next: Testing the Kerberos Server, Prev: Inter-realm Kerberos Operation, Up: Installing the KDC
> tree. It is, however, very rough, and it will likely be significantly
> changed or replaced before the 1.0 release. Hence, this manual does not
This implies there will be a 1.0 release. Better be careful.
This node has the same wording/implication issues about admin server vs.
kdb5_edit I mentioned above.
> File: install, Node: Testing the Kerberos Server, Prev: The Administration Server, Up: Installing the KDC
> # [K_USER]/kinit [USERNAME]
Let's not use # as the default. Don't encourage users to run things
as root that they shouldn't. This means you.
> File: install, Node: Migrating from V4 to V5 Kerberos, Next: A Sample Application, Prev: Installing the KDC, Up: Installation
> To be written.
Reference src/kdc/migration.doc. People won't find it otherwise.
> File: install, Node: Levels of Security, Next: Preparing a Workstation for Kerberos Application Servers, Prev: Installing Kerberos Applications, Up: Installing Kerberos Applications
> Before installing Kerberized servers, it is a good idea to decide on
> a security policy for your workstation. While developing a
"workstation"? Perhaps "environment"?
> provide confidentiality--encryption is required to make sure a
> passive eavesdropper does not collect sensitive data, such as
> passwords, typed over connections. Besides providing
s/typed/sent/
Kerberos is used for noninteractive purposes.
> authenticated session.l
remove spurious letter "l".
> attack is generally limited to the lifetime of a session--it is
> difficult to start a new session if a Kerberos authentication
> exchange must take place at the beginning of every session.
Replace "start" with "spoof" and rewrite sentence.
> services; not everyone has Kerberos or other
> cryptographically-secure network services. Second, in some
This did not hyphenate right. If texinfo experts feel like figuring
out why, good luck.
It is misleading to state that host-based services are necessarily
less secure than passworded services. In some environments
(particularly those firewalled or those that use host-level
encryption, like IPsec), it is more reasonable to trust IP addresses
than passwords (additionally sending passwords may allow them to be
eavesdropped and then later used; if the attacker is not capable of
forging IP packets, host-based services are more secure).
> host-based services.These services use an IP address or
Needs space after period.
> cache in Kerberos4makes these active attacks much easier. Also, design
Needs spaces.
Throughout this node (and perhaps the whole document and I didn't notice)
you use "Kerberos4" and "Kerberos V5". Pick ONE! (format, that is)
> Therefore, if Kerberos4 interoperability is desired or required, try
> to avoid running unencrypted Kerberos4 services wherever possible. In
> particular, only enable encrypted `rlogin' if at all possible.
Huh? Isn't "telnet -ax site <PAUSE> ^[ enc stat" the most secure option?
functionality, like `rsh'.The Kerberos V5 versions of these services,
Needs space.
> with Kerberos4 interoperability enabled are not any weaker than their
comma after "enabled".
> Finally, the issue of compatibility with older Kerberos V5 clients
This is not the last paragraph. Remove "Finally".
> for checksums can be disabled on the server. This results in slightly
> less secure operation, but allows for compatibility with the older
Please avoid the use of unclear terms like "slightly" in these contexts.
> In conclusion, as you prepare to install Kerberos clients, you
clients? Not servers?
> File: install, Node: BSD Utilities, Next: Telnet and FTP, Prev: Preparing a Workstation for Kerberos Application Servers, Up: Installing Kerberos Applications
> `kshd' and `klogind'.The `klogind' server implementsthe protocol used
Spaces.
> older client tries to connect. This option is incompatible with
> Kerberos V4, Kerberos V4 clients do not include a checksum. If
Replace comma with semicolon or emdash.
> validated if they are present, but not required.This is compatible
SPACES!
This section could benefit from an FSM flow diagram, if someone is bored.
> File: install, Node: Common Kerberos Service Names, Prev: Installing Kerberos Applications, Up: Installation
> Used by `telnet', `rlogin', `rsh', `rcp', `ftp'and other services
spaces.
Consider mentioning "discuss" and whatever k5 uses instead of "changepw".
--the end
