DOCSLIB.ORG

Pluggable Authentication Modules

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Pluggable Authentication Modules Pluggable Authentication Modules Dag-Erling Smørgrav Revision: d8432b1e37 Copyright © 2001, 2002, 2003 Networks Associates Technology, Inc. This article was written for the FreeBSD Project by ThinkSec AS and Network Associates Lab- oratories, the Security Research Division of Network Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA CHATS research program. FreeBSD is a registered trademark of the FreeBSD Foundation. Linux is a registered trademark of Linus Torvalds. Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the United States and other countries. Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or registered trademarks of Sun Microsys- tems, Inc. in the United States and other countries. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the “™” or the “®” symbol. Abstract This article describes the underlying principles and mechanisms of the Pluggable Authenti- cation Modules (PAM) library, and explains how to configure PAM, how to integrate PAM into applications, and how to write PAM modules. Table of Contents 1. Introduction ........................................................................................................................... 1 2. Terms and Conventions ............................................................................................................. 2 3. PAM Essentials ........................................................................................................................ 4 4. PAM Configuration ................................................................................................................... 6 5. FreeBSD PAM Modules .............................................................................................................. 8 6. PAM Application Programming .................................................................................................. 10 7. PAM Module Programming ....................................................................................................... 10 A. Sample PAM Application .......................................................................................................... 11 B. Sample PAM Module ............................................................................................................... 14 C. Sample PAM Conversation Function ........................................................................................... 16 Further Reading ........................................................................................................................ 18 1. Introduction The Pluggable Authentication Modules (PAM) library is a generalized API for authentication-related services which allows a system administrator to add new authentication methods simply by installing new PAM modules, and to modify authentication policies by editing configuration les. Terms and Conventions PAM was defined and developed in 1995 by Vipin Samar and Charlie Lai of Sun Microsystems, and has not changed much since. In 1997, the Open Group published the X/Open Single Sign-on (XSSO) preliminary specification, which standardized the PAM API and added extensions for single (or rather integrated) sign-on. At the time of this writing, this specification has not yet been adopted as a standard. Although this article focuses primarily on FreeBSD 5.x, which uses OpenPAM, it should be equally applicable to FreeBSD 4.x, which uses Linux-PAM, and other operating systems such as Linux and Solaris™. 2. Terms and Conventions 2.1. Definitions The terminology surrounding PAM is rather confused. Neither Samar and Lai's original paper nor the XSSO spec- ification made any attempt at formally defining terms for the various actors and entities involved in PAM, and the terms that they do use (but do not define) are sometimes misleading and ambiguous. The rst attempt at es- tablishing a consistent and unambiguous terminology was a whitepaper written by Andrew G. Morgan (author of Linux-PAM) in 1999. While Morgan's choice of terminology was a huge leap forward, it is in this author's opinion by no means perfect. What follows is an attempt, heavily inspired by Morgan, to define precise and unambiguous terms for all actors and entities involved in PAM. account The set of credentials the applicant is requesting from the arbitrator. applicant The user or entity requesting authentication. arbitrator The user or entity who has the privileges necessary to verify the applicant's credentials and the authority to grant or deny the request. chain A sequence of modules that will be invoked in response to a PAM request. The chain includes information about the order in which to invoke the modules, what arguments to pass to them, and how to interpret the results. client The application responsible for initiating an authentication request on behalf of the applicant and for obtaining the necessary authentication information from him. facility One of the four basic groups of functionality provided by PAM: authentica- tion, account management, session management and authentication token update. module A collection of one or more related functions implementing a particular au- thentication facility, gathered into a single (normally dynamically loadable) binary le and identified by a single name. policy The complete set of configuration statements describing how to handle PAM requests for a particular service. A policy normally consists of four chains, one for each facility, though some services do not use all four facilities. server The application acting on behalf of the arbitrator to converse with the client, retrieve authentication information, verify the applicant's credentials and grant or deny requests. service A class of servers providing similar or related functionality and requiring similar authentication. PAM policies are defined on a per-service basis, so all servers that claim the same service name will be subject to the same policy. session The context within which service is rendered to the applicant by the server. One of PAM's four facilities, session management, is concerned exclusively with setting up and tearing down this context. 2 Pluggable Authentication Modules token A chunk of information associated with the account, such as a password or passphrase, which the applicant must provide to prove his identity. transaction A sequence of requests from the same applicant to the same instance of the same server, beginning with authentication and session set-up and ending with session tear-down. 2.2. Usage Examples This section aims to illustrate the meanings of some of the terms defined above by way of a handful of simple examples. 2.2.1. Client and Server Are One This simple example shows alice su(1)'ing to root. % whoami alice % ls -l `which su` -r-sr-xr-x 1 root wheel 10744 Dec 6 19:06 /usr/bin/su % su - Password: xi3kiune # whoami root • The applicant is alice. • The account is root. • The su(1) process is both client and server. • The authentication token is xi3kiune. • The arbitrator is root, which is why su(1) is setuid root. 2.2.2. Client and Server Are Separate The example below shows eve try to initiate an ssh(1) connection to login.example.com, ask to log in as bob, and succeed. Bob should have chosen a better password! % whoami eve % ssh [email protected] [email protected]'s password: god Last login: Thu Oct 11 09:52:57 2001 from 192.168.0.1 Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.4-STABLE (LOGIN) #4: Tue Nov 27 18:10:34 PST 2001 Welcome to FreeBSD! % • The applicant is eve. • The client is Eve's ssh(1) process. • The server is the sshd(8) process on login.example.com • The account is bob. • The authentication token is god. • Although this is not shown in this example, the arbitrator is root. 3 PAM Essentials 2.2.3. Sample Policy The following is FreeBSD's default policy for sshd: sshd auth required pam_nologin.so no_warn sshd auth required pam_unix.so no_warn try_first_pass sshd account required pam_login_access.so sshd account required pam_unix.so sshd session required pam_lastlog.so no_fail sshd password required pam_permit.so • This policy applies to the sshd service (which is not necessarily restricted to the sshd(8) server.) • auth, account, session and password are facilities. • pam_nologin.so, pam_unix.so, pam_login_access.so, pam_lastlog.so and pam_permit.so are modules. It is clear from this example that pam_unix.so provides at least two facilities (authentication and account manage- ment.) 3. PAM Essentials 3.1. Facilities and Primitives The PAM API offers six different authentication primitives grouped in four facilities, which are described below. auth Authentication. This facility concerns itself with authenticating the applicant and establishing the account cre- dentials. It provides two primitives: • pam_authenticate(3) authenticates the applicant, usually by requesting an authentication token and com- paring it with a value stored in a database or obtained from an authentication server. • pam_setcred(3) establishes account credentials such as user ID, group membership and resource limits.
Load more

Recommended publications
  • Mysql NDB Cluster 7.5.16 (And Later)
    Licensing Information User Manual MySQL NDB Cluster 7.5.16 (and later) Table of Contents Licensing Information .......................................................................................................................... 2 Licenses for Third-Party Components .................................................................................................. 3 ANTLR 3 .................................................................................................................................... 3 argparse .................................................................................................................................... 4 AWS SDK for C++ ..................................................................................................................... 5 Boost Library ............................................................................................................................ 10 Corosync .................................................................................................................................. 11 Cyrus SASL ............................................................................................................................. 11 dtoa.c ....................................................................................................................................... 12 Editline Library (libedit) ............................................................................................................. 12 Facebook Fast Checksum Patch ..............................................................................................
    [Show full text]
  • Pluggable Authentication Modules
    Who this book is written for This book is for experienced system administrators and developers working with multiple Linux/UNIX servers or with both UNIX and Pluggable Authentication Windows servers. It assumes a good level of admin knowledge, and that developers are competent in C development on UNIX-based systems. Pluggable Authentication Modules PAM (Pluggable Authentication Modules) is a modular and flexible authentication management layer that sits between Linux applications and the native underlying authentication system. The PAM framework is widely used by most Linux distributions for authentication purposes. Modules Originating from Solaris 2.6 ten years ago, PAM is used today by most proprietary and free UNIX operating systems including GNU/Linux, FreeBSD, and Solaris, following both the design concept and the practical details. PAM is thus a unifying technology for authentication mechanisms in UNIX. This book provides a practical approach to UNIX/Linux authentication. The design principles are thoroughly explained, then illustrated through the examination of popular modules. It is intended as a one-stop introduction and reference to PAM. What you will learn from this book From Technologies to Solutions • Install, compile, and configure Linux-PAM on your system • Download and compile third-party modules • Understand the PAM framework and how it works • Learn to work with PAM’s management groups and control fl ags • Test and debug your PAM confi guration Pluggable Authentication Modules • Install and configure the pamtester utility
    [Show full text]
  • Name Synopsis Description
    UTMP(5) Linux Programmer’sManual UTMP(5) NAME utmp, wtmp − login records SYNOPSIS #include <utmp.h> DESCRIPTION The utmp file allows one to discoverinformation about who is currently using the system. There may be more users currently using the system, because not all programs use utmp logging. Warning: utmp must not be writable by the user class "other", because manysystem programs (foolishly) depend on its integrity.You risk faked system logfiles and modifications of system files if you leave utmp writable to anyuser other than the owner and group owner of the file. The file is a sequence of utmp structures, declared as follows in <utmp.h> (note that this is only one of sev- eral definitions around; details depend on the version of libc): /* Values for ut_type field, below */ #define EMPTY 0/*Record does not contain valid info (formerly known as UT_UNKNOWN on Linux) */ #define RUN_LVL 1/*Change in system run-level (see init(8)) */ #define BOOT_TIME 2/*Time of system boot (in ut_tv)*/ #define NEW_TIME 3/*Time after system clock change (in ut_tv)*/ #define OLD_TIME 4/*Time before system clock change (in ut_tv)*/ #define INIT_PROCESS 5/*Process spawned by init(8) */ #define LOGIN_PROCESS 6 /* Session leader process for user login */ #define USER_PROCESS 7/*Normal process */ #define DEAD_PROCESS 8/*Terminated process */ #define ACCOUNTING 9/*Not implemented */ #define UT_LINESIZE 32 #define UT_NAMESIZE 32 #define UT_HOSTSIZE 256 struct exit_status { /* Type for ut_exit, below */ short int e_termination; /* Process termination status */ short int
    [Show full text]
  • Filesystem Hierarchy Standard
    Filesystem Hierarchy Standard LSB Workgroup, The Linux Foundation Filesystem Hierarchy Standard LSB Workgroup, The Linux Foundation Version 3.0 Publication date March 19, 2015 Copyright © 2015 The Linux Foundation Copyright © 1994-2004 Daniel Quinlan Copyright © 2001-2004 Paul 'Rusty' Russell Copyright © 2003-2004 Christopher Yeoh Abstract This standard consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems. All trademarks and copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Permission is granted to make and distribute verbatim copies of this standard provided the copyright and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this standard under the conditions for verbatim copying, provided also that the title page is labeled as modified including a reference to the original standard, provided that information on retrieving the original standard is included, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this standard into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the copyright holder. Dedication This release is dedicated to the memory of Christopher Yeoh, a long-time friend and colleague, and one of the original editors of the FHS.
    [Show full text]
  • UNIX Logs Agent User.S Guide
    IBM Tivoli Monitoring Version 6.2.3 Fix Pack 1 UNIX Logs Agent User’s Guide SC32-9471-05 IBM Tivoli Monitoring Version 6.2.3 Fix Pack 1 UNIX Logs Agent User’s Guide SC32-9471-05 Note Before using this information and the product it supports, read the information in “Notices” on page 99. This edition applies to version 6.2.3 Fix Pack 1 of the IBM Tivoli Monitoring: UNIX Logs Agent (5724-C04) and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright IBM Corporation 2005, 2012. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Tables ...............v HACMP_join_standby situation ......32 HACMP_network_down situation ......32 Chapter 1. Overview of the Monitoring HACMP_network_down_complete situation . 32 Agent for UNIX Logs .........1 HACMP_network_up situation .......32 HACMP_network_up_complete situation . 32 IBM Tivoli Monitoring overview........1 HACMP_node_down situation .......33 Features of the Monitoring Agent for UNIX Logs . 1 HACMP_node_down_complete situation . 33 New in this release ............2 HACMP_node_down_local situation .....33 Monitoring Agent for UNIX Logs components . 2 HACMP_node_down_local_complete situation . 33 User interface options ...........3 HACMP_node_down_remote situation ....33 HACMP_node_down_rmt_complete situation . 34 Chapter 2. Requirements and HACMP_node_up situation ........34 configuration for the monitoring agent . 5 HACMP_node_up_complete situation ....34 Requirements for the monitoring agent .....6 HACMP_node_up_local situation ......34 Monitoring syslog files on certain AIX 5.3 systems. 8 HACMP_node_up_local_complete situation . 34 Specifying the log files to monitor .......8 HACMP_node_up_remote situation .....35 Customer configuration file ........8 HACMP_node_up_remote_complete situation . 35 Customer configuration file format ......9 HACMP_release_service_addr situation ....35 Syslog daemon configuration file ......10 HACMP_release_takeover_addr situation .
    [Show full text]
  • The Complete Freebsd
    The Complete FreeBSD® If you find errors in this book, please report them to Greg Lehey <grog@Free- BSD.org> for inclusion in the errata list. The Complete FreeBSD® Fourth Edition Tenth anniversary version, 24 February 2006 Greg Lehey The Complete FreeBSD® by Greg Lehey <[email protected]> Copyright © 1996, 1997, 1999, 2002, 2003, 2006 by Greg Lehey. This book is licensed under the Creative Commons “Attribution-NonCommercial-ShareAlike 2.5” license. The full text is located at http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode. You are free: • to copy, distribute, display, and perform the work • to make derivative works under the following conditions: • Attribution. You must attribute the work in the manner specified by the author or licensor. • Noncommercial. You may not use this work for commercial purposes. This clause is modified from the original by the provision: You may use this book for commercial purposes if you pay me the sum of USD 20 per copy printed (whether sold or not). You must also agree to allow inspection of printing records and other material necessary to confirm the royalty sums. The purpose of this clause is to make it attractive to negotiate sensible royalties before printing. • Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. • For any reuse or distribution, you must make clear to others the license terms of this work. • Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above.
    [Show full text]
  • Bsdcan 2015 UCL Working Group
    BSDCan 2015 UCL Working Group [email protected] Overview The goal of this working group is to develop a template for all future configuration files that is both human readable and writable, but is also hierarchical, expressive, and programmatically editable. Agenda ● Opening: What is UCL ● Presentation of work in progress: converting newsyslog and bhyve to UCL ● Discuss common requirements for configuration files ● Develop a common set of grammar/keys to work across all configuration files ('enabled' activates/deactivates each block, allows disabling default configuration without modifying the default files, ala pkg) Agenda (Continued) ● Discuss layering (/etc/defaults/foo.conf -> /etc/foo.conf -> /etc/foo.conf.d/*.conf -> /usr/local/etc/foo.conf.d/*.conf) ● Discuss required features for management utilities (uclcmd) ● Identify additional targets to UCL-ify ● Develop a universal API for using libucl in various applications, simplify loading configuration into C structs (libfigpar?) What is the Universal Configuration Language? ● Inspired by bind/nginx style configuration ● Fully compatible with JSON, but more liberal in what it accepts, so users do not have to write strict JSON ● Can Output UCL, JSON, or YAML ● Supports handy suffixes like k, mb, min, d ● Can be as simple or as complex as required ● Allows inline comments (# and /* multiline */) ● Validation and Schema support ● Supports includes, macros, and variables Why UCL is great -- all of this is valid param = value; key = “value”; flag = true; section { number = 10k string
    [Show full text]
  • Lynx-Lynxos-Datasheet
    Certifiable RTOS for safety-critical computing The world’s most powerful, open-standards real-time OS LynxOS® 7.0 is a deterministic, hard, to develop highly secure devices for the real-time operating system that provides Internet of Things, maximizing their POSIX-conformant APIs in a small foot- availability and uptime and resistance to print em bedded kernel. LynxOS provides potential cyber threats. Advanced embedded symmetric multi-processing support to take development tools enable fast and efficient • Mission-critical performance and full advantage of multi-threaded applica- deployment of these technologies. reliability—absolute determinism and linear performance scalability tions running on multi-core processors. Included are advanced tool chains, debug- LynxOS supports the most popular reference • Industry-leading openness— gers, and cross-development host support. targets within the Intel and PowerPC archi- Full POSIX conformance LynxOS provides open APIs, robust support tectures including the new 4th generation for the latest networking and I/O technolo- Intel® Core™ i7 and Core™ i5, in addition • Latest technologies for Internet gies, and state-of-the-art security features. to the Freescale QorIQ ‘P’ and ‘T’ communications—advanced series processors. networking feature sets for rapid development of LynxOS is already installed on millions of differentiated products devices worldwide. With the introduction All embedded market segments, includ- of new and easy to implement security func- ing military, aerospace, industrial, medical, tionality, both existing and new customers automotive, and office automation benefit can effectively secure their next generation from these security and networking im- of devices. LynxOS 7 implements a layered provements realized in this next generation LynxOS Ensures: approach to security that allows customers of LynxOS architecture.
    [Show full text]
  • Linux Standard Base Core Specification 2.0.1
    Linux Standard Base Core Specification 2.0 .1 Linux Standard Base Core Specification 2.0 .1 Copyright © 2004 Free Standards Group Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Portions of the text are copyrighted by the following parties: • The Regents of the University of California • Free Software Foundation • Ian F. Darwin • Paul Vixie • BSDI (now Wind River) • Andrew G Morgan • Jean-loup Gailly and Mark Adler • Massachusetts Institute of Technology These excerpts are being used in accordance with their respective licenses. Linux is a trademark of Linus Torvalds. UNIX a registered trademark of the Open Group in the United States and other countries. LSB is a trademark of the Free Standards Group in the USA and other countries. AMD is a trademark of Advanced Micro Devices, Inc. Intel and Itanium are registered trademarks and Intel386 is a trademarks of Intel Corporation. OpenGL is a registered trademark of Silicon Graphics, Inc. Specification Introduction Specification Introduction Table of Contents Foreword .......................................................................................................................................................................i Introduction ...............................................................................................................................................................
    [Show full text]
  • Freebsd Advanced Security Features
    FreeBSD Advanced Security Features Robert N. M. Watson Security Research Computer Laboratory University of Cambridge 19 May, 2007 Introduction ● Welcome! – Introduction to some of the advanced security features in the FreeBSD operating system ● Background – Introduce a series of access control and audit security features used to manage local security – Features appeared between FreeBSD 4.0 and FreeBSD 6.2, and build on the UNIX security model – To talk about new security features, we must understand the FreeBSD security architecture 19 May 2007 2 Post-UNIX Security Features ● Securelevels ● IPFW, PF, IPFilter ● Pluggable ● KAME IPSEC, authentication FAST_IPSEC modules (OpenPAM) ● Access control lists ● Crypto library and (ACLs) tools (OpenSSL) ● Security event audit ● Resource limits ● Mandatory access ● Jails, jail securelevels control (MAC) ● GBDE, GELI ● 802.11 security 19 May 2007 3 Brief History of the TrustedBSD Project ● TrustedBSD Project founded in April, 2000 – Goal to provide trusted operating system extensions to FreeBSD – DARPA funding began in July, 2001 – Continuing funding from a variety of government and industry sponsors – Work ranges from immediately practical to research – While many of these features are production- quality, some are still under development – Scope now also includes Apple's Mac OS X 19 May 2007 4 FreeBSD Security Architecture 19 May 2007 5 FreeBSD Security Architecture ● FreeBSD's security architecture is the UNIX security architecture – Entirely trusted monolithic kernel – UNIX process model – Kernel UIDs/GIDs driven by user-space user mode – Privileged root user – Various forms of access control (permissions, ...) ● Security features discussed here extend this security model in a number of ways 19 May 2007 6 Kernel and User Processes Kernel s s Inter-process e l c l communication c a a c m m e e t t s s y y s s e l i F User User User ..
    [Show full text]
  • Managing Services and Faults in Oracle Solaris 11.1 • January 2014 Contents
    Managing Services and Faults in Oracle® Solaris 11.1 Part No: E29003–02 January 2014 Copyright © 1998, 2014, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS. Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including anyoperating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government. This software or hardware is developed for general use in a variety of information management applications.
    [Show full text]
  • Oracle Solaris Administration Common Tasks
    Oracle® Solaris Administration: Common Tasks Part No: 821–1451–11 December 2011 Copyright © 1998, 2011, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract,and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
    [Show full text]