PAM_AFS_SESSION(5) | pam-afs-session | PAM_AFS_SESSION(5) |
pam_afs_session - AFS PAG and token PAM module
auth optional pam_afs_session.so session required pam_afs_session.so
The AFS session service module for PAM, typically installed at /lib/security/pam_afs_session.so, establishes new AFS sessions and obtains AFS tokens when a new session is opened for a user. It is a shared object that is dynamically loaded by the PAM subsystem as necessary, based on the system PAM configuration. PAM is a system for plugging in external authentication and session management modules so that each application doesn't have to know the best way to check user authentication or create a user session on that system. For details on how to configure PAM on your system, see the PAM man page, often pam(7).
This module provides pam_setcred, pam_open_session, and pam_close_session implementations for AFS. Because pam_setcred is part of the auth PAM group, it also implements a dummy pam_authenticate that always succeeds (otherwise, it can't provide a pam_setcred).
Make sure that this module is NEVER listed as "sufficient" or as the only "required" module in the auth group. Doing so will potentially allow users to log on without any password. There unfortunately isn't a way to work around this and still provide pam_setcred without running afoul of a bug in (at least) Linux PAM 0.99.7.1 and probably earlier that causes authentication to fail when the final module in the auth group returns PAM_IGNORE and "[default=done]" was given as the action.
Here are the actions of this module:
The module will only attempt to obtain tokens if the environment variable KRB5CCNAME is set in the environment, unless otherwise configured (see the always_aklog option). It will always create a new PAG, however.
This module is primarily intended for use with a Kerberos authentication module. It does not itself do any user authentication; it cannot, for instance, be used to authenticate users to a kaserver. While it is intended for use with an aklog that uses Kerberos ticket caches to obtain tokens, it can be used with any aklog implementation (always_aklog may have to be set if no Kerberos ticket cache will be present).
This module performs no authorization checks and does not hook into password changes; it only implements the session functions and pam_setcred.
The AFS session PAM module supports the following configuration options, which may be set in the PAM configuration as arguments listed after "pam_afs_session.so" or in the system krb5.conf.
Some of them take arguments, in which case the argument will be given after "=". The rest are boolean options. To set a boolean option in the PAM configuration, just give the name of the option in the arguments. To set an option that takes an argument, follow the option name with an equal sign ("=") and the value, with no separating whitespace. Whitespace in option arguments is not supported in the PAM configuration files of most PAM implementations.
To set an option for the PAM module in the system krb5.conf file, put that option in the [appdefaults] section. The AFS session PAM module will look for options either at the top level of the [appdefaults] section or in a subsection named "pam-afs-session" (currently, realm-specific configuration is not checked). For example, the following fragment of a krb5.conf file would set aklog_homedir to true and minimum_uid to 100.
[appdefaults] aklog_homedir = true pam-afs-session = { minimum_uid = 100 }
There is no difference to the PAM module whether options are specified at the top level or in a "pam-afs-session" section; the "pam-afs-session" section is supported in case there are options that should be set for the PAM module but not for other applications. For more information on the syntax of krb5.conf, see krb5.conf(5).
If the same option is set in krb5.conf and in the PAM configuration, the latter takes precedent. Note, however, that due to the configuration syntax, there's no way to turn off a boolean option in the PAM configuration that was turned on in krb5.conf.
If the AFS session PAM module is running an external program, this option is implemented by passing a -c flag with the cell as its argument for each listed cell to that program. If aklog_homedir is also set, the -c flags and the -p flag will all be passed to the external program.
In either case, the user's home directory is obtained via getpwnam() based on the username PAM says we are authenticating.
This can be used if your environment doesn't correctly set KRB5CCNAME in the environment for some reason, or if your aklog doesn't rely on a Kerberos ticket cache to obtain tokens (or can find the cache on its own via some other means).
This is the default on Mac OS X, where PAGs are not supported.
Setting notokens also implies retain_after_close, meaning that the AFS session PAM module will also not attempt to delete tokens when the user's session ends.
You may pass options to this program by separating them with commas (or spaces or tabs in krb5.conf or if the configuration syntax of your PAM configuration allows this). For example, the setting:
program=/usr/bin/aklog,-noprdb,-524
will run "/usr/bin/aklog -noprdb -524" as the program to obtain tokens. The arguments are passed directly, not parsed by the shell.
If this option is not set, the default behavior is to call the libkafs function to obtain tokens, if available, and otherwise to use a default path to aklog determined at compile time (the first aklog found on the compiler's path by default). If no aklog could be found at compile time and libkafs isn't used, this option must be set.
The entire PAM environment is passed to aklog as its environment (rather than the environment of the process running the PAM functions).
As mentioned above, this module implements a dummy pam_authenticate function so that it can provide a pam_setcred function. Never list this module as "sufficient" or as the only "required" module or you may allow users to log on without a password.
While spawning an external aklog program, the AFS session PAM module resets the SIGCHLD signal handler to the default handler while the program runs and then restores it afterward. This is done to avoid having aklog interfere with process handling in the calling application, but it means that there's a race condition that can cause children to be incorrectly handled if they exit while aklog is running. There is unfortunately no good solution to this other than building against Heimdal and using the libkafs interface to obtain tokens instead of an external program.
To detect whether AFS is running on the system, the AFS session PAM module temporarily sets a SIGSYS handler before attempting an AFS system call. That handler may also modify a static variable. Neither of these should ideally be done in a PAM module, but there is no other good way of checking for the non-existence of a system call that doesn't crash the application on some operating systems. The PAM module will attempt to restore the previous SIGSYS handler, if any, after the test is done, and the static variable is used in such a way that running it from multiple threads shouldn't be an issue, but be aware that the PAM module is doing this behind the back of the application and may interfere with unusual SIGSYS handlers or similar application actions.
When using the libkafs interface to obtain tokens, be sure that it is configured properly for the type of AFS tokens expected at your site. As of Heimdal 0.7, the default behavior is to contact the krb524 service to translate Kerberos v5 tickets into Kerberos v4 tickets to use as tokens. AFS cells running current server software no longer need this, and if your site doesn't run the krb524 service, this may break token acquisition.
Sites running AFS servers that understand Kerberos-v5-derived tokens should add configuration like:
libkafs = { EXAMPLE.ORG = { afs-use-524 = no } }
to the [appdefaults] section of their krb5.conf files to disable use of the krb524 service. See the Heimdal kafs(3) man page for more information.
Copyright 2015 Russ Allbery <eagle@eyrie.org>
Copyright 2005, 2006, 2007, 2008, 2009, 2010, 2011 The Board of Trustees of the Leland Stanford Junior University
Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.
2015-09-19 | 2.6 |