diff options
Diffstat (limited to 'doc')
-rw-r--r-- | doc/admin/conf_files/krb5_conf.rst | 2 | ||||
-rw-r--r-- | doc/admin/host_config.rst | 2 | ||||
-rw-r--r-- | doc/admin/pkinit.rst | 2 | ||||
-rw-r--r-- | doc/iprop-notes.txt | 2 | ||||
-rw-r--r-- | doc/kadm5/adb-unit-test.tex | 2 | ||||
-rw-r--r-- | doc/kadm5/api-funcspec.tex | 14 | ||||
-rw-r--r-- | doc/kadm5/api-server-design.tex | 16 | ||||
-rw-r--r-- | doc/kadm5/api-unit-test.tex | 30 | ||||
-rw-r--r-- | doc/mitK5features.rst | 2 | ||||
-rw-r--r-- | doc/rpc/design.tex | 14 |
10 files changed, 43 insertions, 43 deletions
diff --git a/doc/admin/conf_files/krb5_conf.rst b/doc/admin/conf_files/krb5_conf.rst index f682255..1d2aa7f 100644 --- a/doc/admin/conf_files/krb5_conf.rst +++ b/doc/admin/conf_files/krb5_conf.rst @@ -1123,7 +1123,7 @@ PKINIT krb5.conf options specifies **X509_user_identity** on the command line. **pkinit_kdc_hostname** - The presense of this option indicates that the client is willing + The presence of this option indicates that the client is willing to accept a KDC certificate with a dNSName SAN (Subject Alternative Name) rather than requiring the id-pkinit-san as defined in :rfc:`4556`. This option may be specified multiple diff --git a/doc/admin/host_config.rst b/doc/admin/host_config.rst index 91848ff..4e1db02 100644 --- a/doc/admin/host_config.rst +++ b/doc/admin/host_config.rst @@ -92,7 +92,7 @@ to principals from a different realm than the default realm:: # only principals in OTHER.REALM are matched. # # s/@OTHER\.REALM$// removes the realm name, leaving behind the - # principal name as the acount name. + # principal name as the account name. auth_to_local = RULE:[1:$1@$0](.*@OTHER\.REALM)s/@OTHER\.REALM$// # Also allow principals from the default realm. Omit this line diff --git a/doc/admin/pkinit.rst b/doc/admin/pkinit.rst index 8f663f2..45817da 100644 --- a/doc/admin/pkinit.rst +++ b/doc/admin/pkinit.rst @@ -46,7 +46,7 @@ interoperability issues in rare circumstances. The result of these commands will be two files, cakey.pem and cacert.pem. cakey.pem will contain a 2048-bit RSA private key, which must be carefully protected. cacert.pem will contain the CA -certificate, which must be placed in the filesytems of the KDC and +certificate, which must be placed in the filesystems of the KDC and each client host. cakey.pem will be required to create KDC and client certificates. diff --git a/doc/iprop-notes.txt b/doc/iprop-notes.txt index 722b039..ac57305 100644 --- a/doc/iprop-notes.txt +++ b/doc/iprop-notes.txt @@ -90,7 +90,7 @@ backwards-incompatible ABI changes.) Overflow checks for ulogentries times block size? -If file can't be made the size indicated by ulogentries, shoud we +If file can't be made the size indicated by ulogentries, should we truncate or error out? If we error out, this could blow out when resizing the log because of a too-large log entry. diff --git a/doc/kadm5/adb-unit-test.tex b/doc/kadm5/adb-unit-test.tex index 987af1a..0595c67 100644 --- a/doc/kadm5/adb-unit-test.tex +++ b/doc/kadm5/adb-unit-test.tex @@ -53,7 +53,7 @@ Unit Test Description} The following is a description of a black-box unit test of the OpenV*Secure Admin Database API (osa_adb). Each API function is -listed, followed by the tests that shoud be performed on it. +listed, followed by the tests that should be performed on it. The tests described here are based on the ``OV*Secure Admin Server Implementation Design'' revision 1.14. diff --git a/doc/kadm5/api-funcspec.tex b/doc/kadm5/api-funcspec.tex index 76d2bb5..b633cef 100644 --- a/doc/kadm5/api-funcspec.tex +++ b/doc/kadm5/api-funcspec.tex @@ -522,7 +522,7 @@ typedef struct _krb5_key_data { \end{verbatim} % \begin{description} -\item[key_data_ver] The verion number of the structure. Versions 1 +\item[key_data_ver] The version number of the structure. Versions 1 and 2 are currently defined. If key_data_ver is 1 then the key is either a random key (not requiring a salt) or the salt is the normal v5 salt which is the same as the realm and therefore doesn't need to @@ -641,7 +641,7 @@ Before \v{\#include}ing $<$kadm5/admin.h$>$, the programmer can specify the API version number that the program will use by \v{\#define}ing USE_KADM5_API_VERSION; for example, define that symbol to be 1 to use KADM5_API_VERSION_1. This will ensure that the correct -functional protoypes and data structures are defined. If no version +functional prototypes and data structures are defined. If no version symbol is defined, the most recent version supported by the header files will be used. @@ -727,7 +727,7 @@ mismatch \item[KADM5_BAD_LENGTH] Invalid password length \item[KADM5_BAD_POLICY] Illegal policy name \item[KADM5_BAD_PRINCIPAL] Illegal principal name. -\item[KADM5_BAD_AUX_ATTR] Invalid auxillary attributes +\item[KADM5_BAD_AUX_ATTR] Invalid auxiliary attributes \item[KADM5_BAD_HISTORY] Invalid password history count \item[KADM5_BAD_MIN_PASS_LIFE] Password minimum life is greater then password maximum life @@ -735,7 +735,7 @@ then password maximum life \item[KADM5_PASS_Q_CLASS] Password does not contain enough character classes \item[KADM5_PASS_Q_DICT] Password is in the password dictionary -\item[KADM5_PASS_REUSE] Cannot resuse password +\item[KADM5_PASS_REUSE] Cannot reuse password \item[KADM5_PASS_TOOSOON] Current password's minimum life has not expired \item[KADM5_POLICY_REF] Policy is in use @@ -962,7 +962,7 @@ NOTE: kadm5_init is an obsolete function provided for backwards compatibility. It is identical to kadm5_init_with_password. These three functions open a connection to the kadm5 library and -initialize any neccessary state information. They behave differently +initialize any necessary state information. They behave differently when called from local and remote clients. In KADM5_API_VERSION_2, these functions take a kadm5_config_params @@ -1444,7 +1444,7 @@ terminal-based applications will make use of the password reading functionality. If the passwords don't match the string ``New passwords do not match - password not changed.'' will be copied into msg_ret, and the error code KRB5_LIBOS_BADPWDMATCH will be returned. For other errors that -ocurr while reading the new password, copy the string ``<com_err message$>$ +occur while reading the new password, copy the string ``<com_err message$>$ occurred while trying to read new password.'' followed by a blank line and the string specified by CHPASS_UTIL_PASSWORD_NOT_CHANGED into msg_ret and return the error code returned by krb5_read_password. @@ -1951,7 +1951,7 @@ void kadm5_free_policy_ent(kadm5_policy_ent_t policy); \end{verbatim} Free memory that was allocated by a call to kadm5_get_policy. If -the argument is NULL, the function returns succesfully. +the argument is NULL, the function returns successfully. AUTHORIZATION REQUIRED: none (local operation) diff --git a/doc/kadm5/api-server-design.tex b/doc/kadm5/api-server-design.tex index 94e05b8..2cf0fe8 100644 --- a/doc/kadm5/api-server-design.tex +++ b/doc/kadm5/api-server-design.tex @@ -187,7 +187,7 @@ The following functions describe how each context is handled. Any code whose behavior depends on the API version should be written so as to be compatible with future, currently unknown API versions on -the grounds that any particuarly piece of API behavior will most +the grounds that any particular piece of API behavior will most likely not change between versions. For example, in the current system, the code is not written as ``if this is VERSION_1, do X, else if this is VERSION_2, do Y''; instead, it is written as ``if this is @@ -235,7 +235,7 @@ kadm5_ret_t kadm5_get_principal(void *server_handle, Server library functions must know how many and what type of arguments to expect, and must operate on those arguments correctly, based on the API version with which they are invoked. The API version is contained -in the handle that is alwasy passed as their first argument, generated +in the handle that is always passed as their first argument, generated by kadm5_init_* (to which the client specified the API version to use at run-time). @@ -422,7 +422,7 @@ kadm5_get_principal in the server library, it must give that function an API handle that contains the API version requested by the client; otherwise the function semantics might not be correct. One possibility would be for the server to call kadm5_init for each client -request, specifing the client's API version number and thus generating +request, specifying the client's API version number and thus generating an API handle with the correct version, but that would be prohibitively inefficient. Instead, the server dips down in the server library's internal abstraction barrier, using the function @@ -487,7 +487,7 @@ kadm5_chpass_principal did not change between VERSION_1 and VERSION_2, the declarations of both kadm5_get_principal and kadm5_get_policy did. Thus, to use the caller's API handle, kadm5_chpass_principal will have to have a separate code path for each API version, even -though it itself did not change bewteen versions, and duplicate a lot +though it itself did not change between versions, and duplicate a lot of logic found elsewhere in the library. Instead, each API handle contains a ``local-use handle,'' or lhandle, @@ -528,7 +528,7 @@ This scheme might break down if a kadm5 function has to call another kadm5 function to perform operations that they client will see and for its own benefit, since the semantics of the recursively-called kadm5 function may depend on the API version specified and the client may be -depending on a particular version's behavior. Future implementators +depending on a particular version's behavior. Future implementors should avoid creating a situation in which this is possible. \section{Server Main} @@ -710,7 +710,7 @@ and deallocate the db structure. \end{enumerate} Functions which modify the database acquire an exclusive lock, others -acqure a shared lock. osa_adb_iter_T acquires an exclusive lock for +acquire a shared lock. osa_adb_iter_T acquires an exclusive lock for safety but as stated below consequences of modifying the database in the iteration function are undefined. @@ -881,7 +881,7 @@ osa_adb_ret_t osa_adb_iter_T(osa_adb_T_t db, osa_adb_iter_T_func func, Iterates over every entry in the database. For each entry ent in the database db, the function (*func)(data, ent) is called. If func returns an error code, osa_adb_iter_T returns an error code. If all -invokations of func return OSA_ADB_OK, osa_adb_iter_T returns +invocations of func return OSA_ADB_OK, osa_adb_iter_T returns OSA_ADB_OK. The function func is permitted to access the database, but the consequences of modifying the database during the iteration are undefined. @@ -985,7 +985,7 @@ privilege, 0 if it does not. \section{Function Details} This section discusses specific design issues for Admin API functions -that are not addresed by the functional specifications. +that are not addressed by the functional specifications. \subsection{kadm5_create_principal} diff --git a/doc/kadm5/api-unit-test.tex b/doc/kadm5/api-unit-test.tex index bfd6280..0142420 100644 --- a/doc/kadm5/api-unit-test.tex +++ b/doc/kadm5/api-unit-test.tex @@ -54,7 +54,7 @@ Unit Test Description} \section{Introduction} The following is a description of a black-box unit test of the KADM5 -API. Each API function is listed, followed by the tests that shoud be +API. Each API function is listed, followed by the tests that should be performed on it. The tests described here are based on the ``Kerberos Administration @@ -444,7 +444,7 @@ if set with only an admin server name.} \numtest{102.5}{ \Version{KADM5_API_VERSION_2} -\Reason{Obeys the admin_server field of the configuratin parameters, +\Reason{Obeys the admin_server field of the configuration parameters, if set with a host name and port number.} \Conditions{RPC} } @@ -556,7 +556,7 @@ are specified to server-side init.} \numtest{116}{ \Version{KADM5_API_VERSION_2} \Reason{Two calls to init with clients having different privileges -succeedes, and both clients maintain their correct privileges.} +succeeds, and both clients maintain their correct privileges.} \Priority{Bug fix} \Conditions{RPC} \Status{Implemented} @@ -663,7 +663,7 @@ that does not exist, init fails with ENOENT.} \numtest{10}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{client} } @@ -932,7 +932,7 @@ that does not exist, init fails with ENOENT.} \numtest{44}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{RPC} } @@ -1020,7 +1020,7 @@ that does not exist, init fails with ENOENT.} \numtest{14}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{RPC} } @@ -1309,7 +1309,7 @@ no pw_expiration is specified.} \numtest{44}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{RPC} } @@ -1465,7 +1465,7 @@ has non-name-based salt.} \numtest{17}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{RPC} } @@ -1721,7 +1721,7 @@ Base & Modify access? & Own password? & Service & Pass/Fail \\ \hline \numtest{184}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{RPC} } @@ -1901,7 +1901,7 @@ Number & Modify Access? & Own Key? & Service & Pass/Fail & Implemented? \\ \hlin \numtest{34}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{RPC} } @@ -2014,7 +2014,7 @@ keysalts.} \numtest{16}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{RPC} } @@ -2232,7 +2232,7 @@ correct tl_data and no entries whose type is less than 256.} \numtest{31}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{RPC} } @@ -2312,7 +2312,7 @@ correct tl_data and no entries whose type is less than 256.} \numtest{14}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{RPC} } @@ -2486,7 +2486,7 @@ correct tl_data and no entries whose type is less than 256.} \numtest{31}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{RPC} } @@ -2617,7 +2617,7 @@ correct tl_data and no entries whose type is less than 256.} \numtest{22}{ \Priority{Low} -\Reason{Connects to correct server when mutliple handles exist} +\Reason{Connects to correct server when multiple handles exist} \Conditions{RPC} } diff --git a/doc/mitK5features.rst b/doc/mitK5features.rst index 513ecfd..5d286b6 100644 --- a/doc/mitK5features.rst +++ b/doc/mitK5features.rst @@ -112,7 +112,7 @@ Release 1.9 - Plugin to test password quality :ref:`pwqual_plugin` - Plugin to synchronize password changes :ref:`kadm5_hook_plugin` - Parallel KDC - - GSS-API extentions for SASL GS2 bridge :rfc:`5801` :rfc:`5587` + - GSS-API extensions for SASL GS2 bridge :rfc:`5801` :rfc:`5587` - Purging old keys - Naming extensions for delegation chain - Password expiration API diff --git a/doc/rpc/design.tex b/doc/rpc/design.tex index fbd60f9..801034b 100644 --- a/doc/rpc/design.tex +++ b/doc/rpc/design.tex @@ -519,7 +519,7 @@ flavor initialization routine. The service side, however, is more complex. In the normal course of events, an RPC call comes in, is authenticated, and is then dispatched to the appropriate procedure. For client- and service-side authentication flavors to communicate -indepedent of the server implemented above the RPC layer, the +independent of the server implemented above the RPC layer, the service-side flavor must be able to send a reply to the client directly and {\it prevent} the call from being dispatched. @@ -580,7 +580,7 @@ Server Transport Mechanisms & svc_udp.c \\ \section{GSS-API Authentication Flavor} -The following sections describe the implemetation of the GSS-API +The following sections describe the implementation of the GSS-API authentication flavor for Sun RPC. \subsection{Authentication Algorithms} @@ -640,7 +640,7 @@ output token is generated, it is returned to the client. Note that since the application server may have registered multiple service names and there is no way to determine {\it a priori} which service a token is for, _svcauth_gssapi calls gss_accept_sec_context once for -each registered credential until one of them succeedes. The code +each registered credential until one of them succeeds. The code assumes that GSS_S_FAILURE is the only error that can result from a credential mismatch, so any other error terminates the loop immediately. @@ -661,7 +661,7 @@ processed). The reverse is also true. \subsubsection{RPC Calls} After the GSS-API context is established, both the server and the -client posess a client handle and a corresponding sequence number. +client possess a client handle and a corresponding sequence number. Each call from the client contains the client handle as the ``credential'' so that the server can identify which context to apply to the call. @@ -704,7 +704,7 @@ The auth_msg field indicates whether the message is intended for the authentication mechanism for the actual server. Any message whose auth_msg field is true is processed by the authentication mechanism; any message whose auth_msg is false is passed to the application -server's dispatch function if authentication suceeds. All messages +server's dispatch function if authentication succeeds. All messages must have an auth_msg of true until the context is established, since authentication cannot succeed until it is. @@ -876,7 +876,7 @@ an RPC_SUCCESS response is received, verifies that the returned sequence number is one greater than the previous value sent by auth_gssapi_marshall. -Finally, auth_gssapi_unwrap, invokved by the client-side RPC mechanism +Finally, auth_gssapi_unwrap, invoked by the client-side RPC mechanism after auth_gssapi_validate succeeds, performs the same operation as svc_auth_gssapi_unwrap. @@ -940,7 +940,7 @@ calls except the first one; the handle is obtained as the result of the first call. The sequence_number field contains the sequence number that will be -used when transmitting RPC calls to the server and verifing the +used when transmitting RPC calls to the server and verifying the server's responses after the context is initialized. The def_cred field is true if gss_init_sec_context created a default |