mirror of
https://git.openafs.org/openafs.git
synced 2025-01-31 05:27:44 +00:00
198a4c970e
The krb5_524_conv_principal() function should fail whenever the Kerberos
v5 principal cannot safely be mapped onto a Kerberos v4 principal, and
does fail on some Kerberos v5 principals used in real-world AFS
deployments.
Prior to this patchset a failure was treated as a fatal error that
in turn prevents an AFS token from being generated or set into the
cache manager.
Prior to b1f9b4cb5dd295162ae51704310e9d6058008f0a the
krb5_524_conv_principal() function wasn't used and a local client
mapping was created. b1f9b4cb5dd295162ae51704310e9d6058008f0a
replaced the local mapping with the krb5 function because the local
mapping could be wrong and confusing.
The krb5_524_conv_principal() function as applied to AFS tokens is
just a local guess. How the username in the token is interpreted by
the AFS server is up to the server.
krb5_524_conv_principal() is only used for Krb5 native tokens. For Krb4
tokens the krb5_524_convert_creds() function is used to obtain both the
Kerberos v4 ticket and the converted names from the KDC. Many
organizations used the krb524d service to perform name translation. When
the krb524d service is used, the name translation is performed by the KDC,
so there is no local call to krb5_524_conv_principal() which might fail.
As a result, disallowing the use of a native Krb5 token due to a failed
local name translation is a needless loss of functionality; the local name
translation is not an essential part of obtaining a token.
This patchset modifies the behavior such that krb5_524_conv_principal()
errors are non-fatal.
1. If -noprdb is not specified the error message is generated
and a NULL username is used.
2. If the username is NULL the prdb lookup is disabled.
3. If the username is NULL the informational messages do not
include a username.
4. If the username is NULL the username info provided to the
cache manager in the token description is the nul string.
This patchset is an openafs-stable-1_6_x specific version of
the patch. The master version was submitted to
http://gerrit.openafs.org/#change,11542
Credit to Ben Kaduk for assistance with the wording of this commit
message.
Change-Id: If12ae69394321fa7b7a182c9db95716bc66e489c
Reviewed-on: http://gerrit.openafs.org/11538
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
What's in the "doc" subdirectory ** doc/html original IBM html doc, no longer used ** doc/man-pages pod sources for man pages (converted from original IBM html source). ** doc/xml xml sources for manuals (converted from original IBM html source). there is some generated pdf/html content as well for the curious. Note that doc/xml/AdminReference uses doc/xml/AdminReference/pod2refentry to convert the pod man pages to xml for printing. pod goes directly to html just fine. The reference guide is now built by converting the existing pod documentation to xml. however, the indexing information was lost during the initial pod conversion. Someone we will need to try to get that back. ** doc/pdf old Transarc (and possibly pre-Transarc) protocol and API documentation for which we have no other source ** doc/txt doc/examples a few other miscellaneous files. From: Russ Allbery The Administrative Reference has been converted into separate POD man pages for each command, since that's basically what it already was (just in HTML). Considerable work remains to update that POD documentation to reflect the current behavior of OpenAFS (for example, there's no documentation of dynroot, no mention of Kerberos v5, many fileserver options are undocumented, the afsd switch documentation is out of date, and so forth). I've collected as many of those deficiencies as I know of in doc/man-pages/README. Any contributions to correct any of those deficiencies are very welcome. This is one easy place to start. The other reference manuals (the Administrator's Guide, the Quick Start Guide, and the User's Guide) are more manual-like in their structure. After some on-list discussion, we picked DocBook as the format to use going forward and the existing HTML files have been converted to DocBook with a script. This means that the markup could use a lot of cleaning up and the content is even less updated than the man pages. I did some *very* initial work on the Quick Start Guide, just to get the makefile working and to try some simple modifications. Simon Wilkinson is currently working on making more extensive modifications. If you want to work on the Quick Start Guide, please coordinate with him to avoid duplicate work. The Administrator's Guide and User's Guide have not yet been touched. Of those, the latter is probably in the best shape, in that the user commands and behavior haven't changed as much. If you'd like to start working on one of those, that would also be great.