pam_timestamp(8) System Administrator's Manual pam_timestamp(8)NAME
pam_timestamp - authenticate using cached successful authentication attempts
SYNOPSIS
auth sufficient /lib/security/pam_timestamp.so
session optional /lib/security/pam_timestamp.so
DESCRIPTION
In a nutshell, pam_timestamp caches successful authentication attempts, and allows you to use a recent successful attempt as the basis for
authentication.
When an application opens a session using pam_timestamp, a timestamp file is created in the timestampdir directory for the user. When an
application attempts to authenticate the user, a pam_timestamp will treat a sufficiently- recent timestamp file as grounds for succeeding.
ARGUMENTS
debug turns on debugging via syslog(3).
timestampdir=name
tells pam_timestamp.so where to place and search for timestamp files. This should match the directory configured for sudo(1) in the
sudoers(5) file.
timestamp_timeout=number
tells pam_timestamp.so how long it should treat timestamp files as valid after their last modification date. This should match the
value configured for sudo(1) in the sudoers(5) file.
verbose
attempt to inform the user when access is granted.
EXAMPLE
/etc/pam.d/some-config-tool:
auth sufficient /lib/security/pam_timestamp.so verbose auth required /lib/security/pam_unix.so
session required /lib/security/pam_permit.so session optional /lib/security/pam_timestamp.so
CAVEATS
Users can get confused when they aren't always asked for passwords when running a given program. Some users reflexively begin typing
information before noticing that it's not being asked for.
SEE ALSO pam_timestamp_check(8)BUGS
Let's hope not, but if you find any, please email the author.
AUTHOR
Nalin Dahyabhai <nalin@redhat.com>
Red Hat Linux 2002/02/07 pam_timestamp(8)
Check Out this Related Man Page
pam_console(8) System Administrator's Manual pam_console(8)NAME
pam_console - determine user owning the system console
SYNOPSIS
session optional pam_console.so
auth required pam_console.so
DESCRIPTION
pam_console.so is designed to give users at the physical console (virtual terminals and local xdm-managed X sessions by default, but that
is configurable) capabilities that they would not otherwise have, and to take those capabilities away when the are no longer logged in at
the console. It provides two main kinds of capabilities: file permissions and authentication.
When a user logs in at the console and no other user is currently logged in at the console, pam_console.so will run handler programs speci-
fied in the file /etc/security/console.handlers such as pam_console_apply which changes permissions and ownership of files as described in
the file /etc/security/console.perms. That user may then log in on other terminals that are considered part of the console, and as long as
the user is still logged in at any one of those terminals, that user will own those devices. When the user logs out of the last terminal,
the console may be taken by the next user to log in. Other users who have logged in at the console during the time that the first user was
logged in will not be given ownership of the devices unless they log in on one of the terminals; having done so on any one terminal, the
next user will own those devices until he or she has logged out of every terminal that is part of the physical console. Then the race can
start for the next user. In practice, this is not a problem; the physical console is not generally in use by many people at the same time,
and pam_console.so just tries to do the right thing in weird cases.
When an application attempts to authenticate the user and this user is already logged in at the console, pam_console.so checks whether
there is a file in /etc/security/console.apps/ directory with the same name as the application servicename, and if such a file exists,
authentication succeeds. This way pam_console may be utilized to run some system applications (reboots, config tools) without root pass-
word, or to enter user password on the first system login only.
ARGUMENTS
debug turns on debugging
allow_nonroot_tty
gain console locks and change permissions even if the TTY's owner is not root.
handlersfile=filename
tells pam_console.so to get the list of the handlers from a different file than /etc/security/console.handlers
EXAMPLE
/etc/pam.d/some-system-tool:
auth sufficient pam_rootok.so
auth required pam_console.so
/etc/pam.d/some-login-service:
auth sufficient pam_console.so
auth required pam_unix.so
session required pam_unix.so
session optional pam_console.so
FILES
/var/run/console/
/var/run/console/console.lock
/etc/security/console.apps
/etc/security/console.handlers
SECURITY NOTES
When pam_console "auth" is used for login services which provide possibility of remote login, it is necessary to make sure the application
correctly sets PAM_RHOST variable, or to deny remote logins completely. Currently, /bin/login (invoked from telnetd) and gdm is OK, others
may be not.
SEE ALSO console.perms(5)console.apps(5)console.handlers(5)pam_console_apply(8)
/usr/share/doc/pam*/html/index.html
BUGS
Let's hope not, but if you find any, please report them via the "Bug Track" link at http://bugzilla.redhat.com/bugzilla/
AUTHORS
Michael K. Johnson <johnsonm@redhat.com>
Support of console.handlers and other improvements by Tomas Mraz <tmraz@redhat.com>
Red Hat 2005/10/4 pam_console(8)