doc: Fix the AFS::ukernel man page title The pod2man tool determines a man page title (set in the .TH macro) from the input filename, unless the -n (--name) option is specified. Our AFS::ukernel man page input file is named AFS.ukernel.pod to avoid colons in the filename (since colon characters are not supported on Windows), so the generated man page contains the title "AFS.ukernel" instead of "AFS::ukernel". Use the pod2man -n (--name) option when converting section 3 man pages to override the automatic title naming. This fixes the .TH macro in the generated AFS::ukernel.3 file. Fortunately, the -n (--name) option is only needed for section 3 man pages. Specifying the pod2man -n (--name) option is simpler and less invasive than renaming pod3/AFS.ukernel.pod to pod3/lib/AFS/ukernel.pod (which would also fix the embedded title). Change-Id: I495ea2d30ce1b34698519ffa34a39362c449ba09 Reviewed-on: https://gerrit.openafs.org/15363 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Mark Vitale <mvitale@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Add command fallback to server config Add an initialization retry in the bos, vos, and pts commands to fallback to the server configuration directory when initialization fails with the client configuration directory. This allows admins to run unauthenticated bos, vos, and pts commands on servers without a client configuration (including symlinks created by the bosserver) without any extra command line options. Perform the initialization retry only when the -localauth or -config options are not given. The bos, vos, and pts commands already use the server configuration path when the -localauth option is given, so there is no point in retrying the same path. The vos and pts -config option specifies the path to be used, so we do not fallback to a different directory when the user specifies the configuration path to be used. While here, change the scope of the confdir variable in vos.c from a global to a local variable, since it is only used within the MyBeforeProc() function. This change does not add a vsu_ClientInit() retry in the bos salvage command. That command always requires authorization, so when run without -localauth requires a token (and therefore a cache manager and client cell configuration). Update the bos, vos, and pts man pages to describe this new fallback method to lookup the configuration directory. (The AFSCONF environment variable and .AFSCONF files are currently undocumented in the man pages. They should be documented or removed from the code in a future change.) Change-Id: I55c3109494db744e7bc2defcb54eaee3b4e30018 Reviewed-on: https://gerrit.openafs.org/15351 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
doc: Remove stray sect2 end tag Commit 2f435309c75dfd8ffe0cfb3e1a54749437cba3be (Remove NoAuth procedures from Admin Guide) introduced a syntax error in the Admin Reference guide xml source. The </sect2> end tag which matched the <sect2 id="Header_427"> start tag should have been removed in the last hunk of that commit. This change removes the stray end tag to fix the xsltproc error: Build the book set list... openafs/doc/xml/AdminGuide/auagd014.xml:1119: parser error : Opening and ending tag mismatch: sect1 line 1037 and sect2 </sect2> ^ ... Error: xsltproc failed make: *** [Makefile:42: auagd000.pdf] Error 1 Change-Id: I91b9b5335c2ddd6ab60d3bc061703c8396003a43 Reviewed-on: https://gerrit.openafs.org/15120 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
doc: Show correct path to BosConfig when using modern paths The BosConfig.5 man page shows the incorrect path to the BosConfig file when modern installation paths are used. For example, BosConfig.5 man page distributed by Debian contains the text: The file must reside in the /var/lib/openafs/local directory ... which should read: The file must reside in the /etc/openafs directory ... The man page files contain Transarc-style paths which are translated to the configured paths by the install target. The path /usr/afs/local in the BosConfig pod file is interpreted as @afslocaldir@, not the correct @afsbosconfigdir@. Change the BosConfig POD text to trigger a special substitution case in the install-man script. This case is is already in use to correctly translate paths of the BosConfig.new and BosConfig files the bosserver man page. /usr/afs/local/BosConfig -> @afsbosconfigdir@/BosConfig Using this rule requires a change to the text to show the fully qualified path to the BosConfig file, instead of just the directory name. Change-Id: If1c5872dd86c7c1a5de98fb37daef903cd10b26b Reviewed-on: https://gerrit.openafs.org/14908 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
CVE-2018-7168 RXAFS_StoreACL deprecate 134 introduce 164 There exist in the wild AFS3 clients that improperly construct access control lists which are then stored to directories via RXAFS_StoreACL (opcode 134). These clients add negative access control entries (if any) to the normal rights list. As there is no method by which a fileserver can determine that the ACL is improperly constructed, the only method to defend the storage of broken ACLs is to identify clients that are known to properly construct ACLs by introducing a new RXAFS_StoreACL opcode (164). This change: * Renames RXAFS opcode 134 to RXAFS_OldStoreACL * Introduces RXAFS opcode 164 as RXAFS_StoreACL * Implements SRXAFS_OldStoreACL and SRXAFS_StoreACL in the fileserver via a common_StoreACL() function that accepts the executed opcode as input. * To avoid breaking changes in stable release branches, SRXAFS_OldStoreACL will still be allowed by default, with an option to cause it to be failed by default with error EPERM/UAEPERM. A follow-up commit will cause SRXAFS_OldStoreACL to fail by default on the master branch. * When opcode 134 is called, the a FileLog entry will be generated at log level 0 instead of 1 and the entry will contain the string "CVE-2018-7168". * Modifies the format of the ACL logged to the FileLog and the audit stream. Previously the AFSOpaque format was used directly. The problem with this format is that it uses newlines as the ACE separator. Since the FileLog and file audit log is intended to be one line per log entry, the newlines break the file formats. This change replaces the newlines with spaces for display purposes unless the process is unable to allocate the additional memory. * Introduces a new fileserver command line switch -cve-2018-7168-enforce which when specified causes SRXAFS_OldStoreACL RPCs to be failed. [kaduk@mit.edu: switch en/disable-by-default behavior and fix argument parsing] Change-Id: Ic92ef45314d75fbc2b8ff574223fab2d398a1d60 FIXES: 134485 Reviewed-on: https://gerrit.openafs.org/12942 Reviewed-by: Jeffrey Altman <jaltman@auristor.com> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
fs: add option to evaluate symlink or mtpt Currently, several fs subcommands for Windows offer an option (-literal) to evaluate symlink / mount point rather than the object it refers to. Provide the same option on Unix for fs_getfid. Change-Id: I55ab5f96d5b9e63efbe7e938647edba05a1787ed Reviewed-on: https://gerrit.openafs.org/14542 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
fstrace: add dump -debug option As a debugging aid, add a -debug option to the dump subcommand to display each trace record in raw hex format as well as the normal decoded format. Change-Id: I80dd675a07e048e25749a9afb584515effcbc08a Reviewed-on: https://gerrit.openafs.org/14557 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Remove NoAuth procedures from Admin Guide Retain the factual description of what the file/flag does, but remove the suggestion that it is useful in favor of a disclaimer that it is not needed, and replace the emergency-recovery procedure with a short description using -localauth. Change-Id: I18b0dad9740f01515717d572a0374cd2f77fc02d Reviewed-on: https://gerrit.openafs.org/14638 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Remove recommendation to use NoAuth from NoAuth.5 Do not document that there are cases when this file should exist; there are not. Installation no longer needs this file, and key emergencies can be handled using asetkey or, on 1.8.x, the kerberos tooling to modify rxkad.keytab. Change-Id: I0c3ba15f3ffca8660be2d8b092f10053258742e6 Reviewed-on: https://gerrit.openafs.org/12142 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Tested-by: Benjamin Kaduk <kaduk@mit.edu>
doc: Look in $srcdir for documentation sources In several places, we look for documentation source files in e.g. 'doc/man-pages', 'doc/xml', etc. But if we are running an objdir build, those directories won't exist relative to the current working directory; we need to look in $srcdir to find them. So, if we're running an objdir build, our man pages and other documentation won't be installed. We don't report any error in this case (the relevant steps are just skipped), since building the documentation is optional, in case the doc sources are not present. To fix this, look in $srcdir in the various places that reference doc source files. Fixing the 'for' loops in the 'dest' and 'install' targets in doc/man-pages requires some extra cd'ing around, because $M is used as part of another path in the body of the loop. Change-Id: Ic3c90ab5e64aeefe6235efb6f6ec26080d7b3a70 Reviewed-on: https://gerrit.openafs.org/14622 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
kauth: Add support for updated audit facility New functionality was added to the audit facility that allows multiple audit logs. The updated audit interfaces require a specific calling sequence even if multiple audit logs are not used. Support for multiple auditlogs is not supported for kauth. Since kauth does not use libcmd for processing the command line, and adding support for multiple audit log instances requires additional effort, that is not warranted. Update kauth to follow the proper calling sequences for the audit facility. Update help message and manpage entries for -auditlog and -audit-interface. Make note that multiple -auditlogs are not supported. Change-Id: I98111b1e399e6687fde235bc2eadf0a28fa8acf4 Reviewed-on: https://gerrit.openafs.org/13782 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Add command line support for multiple audit logs Gerrits #13774 (audit: Support multiple audit interfaces and interface options) and #13775 (audit: Add cmd helper for processing audit options) added support in the audit facility for multiple audit logs. Add command line support to use multiple audit logs for daemons that use libcmd for command line processing: bosserver, buserver, butc, fileserver, volserver, ptserver, and vlserver. Update the daemons to add a call to audit_open, and where possible add a call to audit_close when shutting down the daemon. Update help message and manpage entries for -auditlog and -audit-interface Change-Id: I4356e1aa84f580897a0e788e2a2829685be891aa Reviewed-on: https://gerrit.openafs.org/13776 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
volser: document 'vos restore -readonly' restriction Commit 0c03f8607e15 vos-command-enhancements-20011008 introduced the 'vos restore' -readonly option, which allows the restored volume to be RO instead of the default RW. The commit message documents the following restriction: - ... This option causes the restored volume to be an RO volume. It is not permitted to restore an RO volume when the associated RW volume already exists. While it is possible to restore an RW volume where an RO volume exists, caution should be used to avoid doing this with VLDB entries created by 'vos restore -readonly', since such entries have their ROVOL and RWVOL ID's set to the same thing. Document this restriction in the 'vos restore' man page, and in a code comment. No functional change is incurred by this commit. Change-Id: I34f6c5434b82da538a38a9d219207b33dcf62b17 Reviewed-on: https://gerrit.openafs.org/14348 Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Remove unused xdr types Numerous types and constants are defined in our various RPC-L files that are never used or referenced by anything. Remove them. Change-Id: I0b03be1ce0e186a88f80d2f3f7a66a1e25965ff3 Reviewed-on: https://gerrit.openafs.org/14404 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
xstat: prevent CPU loop when -period 0 Historically xstat_cm_test and xstat_fs_test have supported option '-period <mm>' to specify continuous operaiton for a length of time. If '-period 0' was specified, both programs exited immediately. Beginning with commits 2c1a7e47336c8f8d14dd6c65d53925a9e0e87c66 'xstat: add xstat_*_Wait functions' and 6b67cac432043a43d7cdfa6af972ab54412aff94 'convert xstat and friends to pthreads', xstat_cm_test and xstat_fs_test now support -period 0 to run "forever". This support is implemented in xstat_cm_Wait and xstat_fs_Wait, respectively. Although the "wait forever" logic was added to allow consolidation of similar code in afsmonitor, it also changed how xstat_cm_test and xstat_fs_test behave for '-period 0'. Unfortunately, there is a bug in this support, at least when running on pthreads. After the initial 24 minute timer expires, the while (1) will repeatedly run select with a timeout that is now 0. This causes the while loop to consume 100% of the CPU on which this thread is dispatched. Instead, modify the wait-forever logic to specify NULL for the select() timeout value. Also update the man page to document that '-period 0' means forever. Change-Id: I25d0d5be0eedb8bf3de495785b9b03a3e3d45221 Reviewed-on: https://gerrit.openafs.org/14366 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
volser: Don't NUL-pad failed pread()s in dumps Currently, the volserver SAFSVolDump RPC and the 'voldump' utility handle short reads from pread() for vnode payloads by padding the missing data with NUL bytes. That is, if we request 4k of data for our pread() call, and we only get back 1k of data, we'll write 1k of data to the volume dump stream followed by 3k of NUL bytes, and log messages like this: 1 Volser: DumpFile: Error reading inode 1234 for vnode 5678 1 Volser: DumpFile: Null padding file: 3072 bytes at offset 40960 This can happen if we hit EOF on the underlying file sooner than expected, or if the OS just responds with fewer bytes than requested for any reason. The same code path tries to do the same NUL-padding if pread() returns an error (for example, EIO), padding the entire e.g. 4k block with NULs. However, in this case, the "padding" code often doesn't work as intended, because we compare 'n' (set to -1) with 'howMany' (set to 4k in this example), like so: if (n < howMany) Here, 'n' is signed (ssize_t), and 'howMany' is unsigned (size_t), and so compilers will promote 'n' to the unsigned type, causing this conditional to fail when n is -1. As a result, all of the relevant log messages are skipped, and the data in the dumpstream gets corrupted (we skip a block of data, and our 'howFar' offset goes back by 1). So this can result in rare silent data corruption in volume dumps, which can occur during volume releases, moves, etc. To fix all of this, remove this bizarre NUL-padding behavior in the volserver. Instead: - For actual errors from pread(), return an error, like we do for I/O errors in most other code paths. - For short reads, just write out the amount of data we actually read, and keep going. - For premature EOF, treat it like a pread() error, but log a slightly different message. For the 'voldump' utility, the padding behavior can make sense if a user is trying to recover volume data offline in a disaster recovery scenario. So for voldump, add a new switch (-pad-errors) to enable the padding behavior, but change the default behavior to bail out on errors. Change-Id: Ibd6e76c5ea0dea95e3354d9b34536296f81b4f67 Reviewed-on: https://gerrit.openafs.org/14255 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
rx: fix out-of-range value for RX_CONN_NAT_PING Commit 496fb87372555f6acddd4fd88b03c94c85f48511 ("rx: avoid nat ping until connection is attached") introduced functionality to defer turning on NAT ping for server connections until after reachability had been established for the client. Unfortunately, this feature could never work correctly because it assigned an out-of-range flag value of 256 (0x100) for the u_char flags field. Instead of calling this out as an error, both gcc and Solaris cc elide this flag so that it is never set in rx_SetConnSecondsUntilNatPing(), Furthermore, the test in rxi_ConnClearAttachWait() will always fail; therefore rxi_ScheduleNatKeepAliveEvent is never called after attach wait has ended. Fortunately, this bug is currently moot - not actually exposed in OpenAFS. (It was discovered by inspection). This is because there are currently no rx_connection objects in the tree that have both NAT ping and checkReach (rx_SetCheckReach) enabled. I also searched git history and found no time when this bug could ever have been exposed. This does raise the question of why the original commit was needed; but instead of reverting the original commit, this commit attempts to fix it. To prevent problems if NAT ping and checkReach are ever both enabled for an rx_connection, enlarge the rx_connection flags member so that the RX_CONN_NAT_PING value is no longer out of range. Change-Id: Ib667ece632f66fa5c63a76398acb3153fed6f9c3 Reviewed-on: https://gerrit.openafs.org/13041 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Cleanup vestiges of old shared library build directories Remove traces of the old shlibrpc and shlibafsauthent build directories, which are no longer needed since the conversion to libtool for building shared libraries. Change-Id: I8dbfdf9908b4a5527470b7cb4b969e7a160cdd51 Reviewed-on: https://gerrit.openafs.org/14045 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
vos: fix name availability check in vos rename The UV_RenameVolume() function first updates the volume name in the VLDB, then read-write volume header and backup volume header, and finally all of the read-only volume headers. If this function is interrupted or a remote site is not reachable, the names in some of the volume headers will be out of sync with name in the VLDB entry. The implementation of UV_RenameVolume() is idempotent, so can be safely called with the same name as in the volume's VLDB entry. This could be used to bring all the names in the volume headers in sync with the name in the VLDB. Unfortunately, due to the check of the -newname parameter, vos rename will not invoke UV_RenameVolume() when the name in the VLDB has already been changed. The vos rename command attempts to verify the desired name (-newname) is available before invoking UV_RenameVolume() by simply checking if a VLDB entry exists with that name, and incorrectly assumes when a VLDB entry exists with that name it is an entry for a different volume. Change the -newname check to allow vos rename to proceed when name has already been set in the VLDB entry of the volume being renamed. This allows admins to run vos rename command to complete a previously incomplete rename operation and bring the names in the volume headers in sync with the name in the VLDB entry. Note: Before this commit, administrators could workaround this vos rename limitation by renaming the volume twice, first to an unused volume name, then to the actual desired volume name. Remove the useless checks of the code1 return code after exit in the RenameVolume() function. These checks for code1 are never performed since the function exits early when the first VLDB_GetEntryByName() fails for any reason. Update the vos rename man page to show vos rename can be used to fix previously interrupted/failed rename. Also document the -oldname parameter accepts a numeric volume id to specify the volume to be renamed. Change-Id: Ibb5dbe3148e9b8295347925a59cd7bdbccbe8fe0 Reviewed-on: https://gerrit.openafs.org/13720 Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>