Section A.1. PAM Principles


A.1. PAM Principles

In Linux's early days, every server or other tool that had to authenticate users did so by reading /etc/password, the traditional Unix account file. This approach was easy to implement, but it had several problems. One of these was that the file, and hence the encrypted password, had to be readable by all users, making it vulnerable to cracking. Another problem is that changes to authentication methods, such as new password-encryption systems, required changes to all the programs that could authenticate users. This problem would result in a nightmarish tangle of upgrades should an administrator ever want to change the authentication system.

PAM is designed to solve these problems. PAM solves the problem of world readability of /etc/passwd by implementing a system known as shadow passwords, in which passwords are moved out of /etc/passwd and into a file that can be read only by roottypically /etc/shadow on Linux systems. (Shadow passwords can be implemented without PAM, but today PAM is the tool that does it on all major Linux distributions.) PAM helps minimize the pain of changing authentication systems by working as a layer between the tools that authenticate users and the account database. Instead of accessing /etc/passwd directly, programs consult PAM, which accesses /etc/passwd. Thus, if the format of data in /etc/passwd changes, individual servers don't need to be rewritten or even recompiled; only PAM must change. Indeed, PAM can be changed to support authentication systems that don't even consult /etc/passwd. It's this feature of PAM that Winbind, LDAP authentication, and some Kerberos tools use. Rather than consult /etc/passwd, PAM consults the appropriate network authentication tool.

In addition to PAM, Linux relies on another software component, the Name Service Switch, for account information. Rather than authentication information, though, NSS provides more mundane information, such as a mapping of UIDs to usernames and the account's default shell. Like PAM, NSS is designed in a modular way and sits between applications that ask for this information and the actual account databases. Although you may think in terms of authentication, which is what PAM provides, this ancillary information is just as important, so you must configure NSS to link to your authentication system. The chapters on Winbind and LDAP describe configuring NSS to work with these tools, but Kerberos provides no NSS interface, which is a limitation of Kerberos if you want a network authentication system to handle all your account information.


In practice, PAM is a modular tool: it consults libraries to handle various parts of the authentication procedure. You tell PAM which libraries to consult with the help of the PAM configuration files, which are described in the next section. Thus, the overall authentication system, and its equivalent in pre-PAM days, are depicted in Figure A-1. PAM's modular nature is manifested in this figure by the fact that PAM is shown accessing three independent authentication toolsthe /etc/passwd file, an NT domain controller, and an LDAP server. A default configuration is likely to be simpler than this, but if you want to use a network authentication tool, chances are you'll leave the old-style /etc/passwd authentication intact as a backup and to provide information for accounts you might not want to define using a centralized system, such as the root account.

Figure A-1. PAM distances servers and other programs that require authentication from authentication implementations, increasing flexibilityand complexity


In practice, PAM configuration is even more complex than Figure A-1 suggests, for three reasons:

  • PAM provides management features beyond those related to account authentication. In particular, it supports authentication (verifying that users are who they claim to be), account management (checking for expired accounts, the right to use a particular server, and so on), session management (login and logout housekeeping), and password changes. Each management system must be configured individually; for instance, the modules called in service of authentication may be different than those required for session management.

  • A single act, such as logging in, may require multiple PAM modules. For instance, many PAM login configurations call a module called pam_deny.so, which explicitly denies access to the system if no earlier module has explicitly granted access. You can even tack on modules that aren't directly related to authentication, such as modules that display login notices.

  • Each program that requires PAM's services may be configured individually. For instance, you might want to use one set of options for authenticating users for console logins and another for authenticating users to use the su command to change their effective UID numbers.



    Linux in a Windows World
    Linux in a Windows World
    ISBN: 0596007582
    EAN: 2147483647
    Year: 2005
    Pages: 152

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net