Bugs in pam_timestamp module

I have played a bit with pam_timestamp module. With the module, one can configure some application to grant access to the user, if the user has already authenticated recently. This is useful for various configuration tools (for example, RedHat's system-config-<xxx> series), and can get a feeling of Single-Sign-On.

To demonstrate, I'll use su command. Here is its pam configuration file.

NOTE: this is sample configuration - do not use this in real environments

auth       sufficient    pam_rootok.so
auth       sufficient    pam_timestamp.so verbose
auth       include       system-auth
account    include       system-auth
password   include       system-auth
session    include       system-auth
session    optional      pam_timestamp.so

When you su for the first time, session part of the configuration creates timestamp. Next time you su from the same terminal auth part will grant you access if recorded timestamp is recent enough.

This is what is supposed to work. In practice, it works only if you login on /dev/ttyx. After ensuring that configuration is fine, I've started digging into sources, and have discovered, that checks for tty device file sanity are pretty loose:

The supposed tty name should not contain / character, and if it does, then tty name is something in the form /dev/ttyx. This rule ceases to work when you use, say, xterm and your tty in like pts/14.

I've decided to replace those policies with the following:

Complement received tty name to full device file string.

Execute access system call to ensure the terminal device file is writable by the user.

I've created patch that fixes the situation. The patch is relevant for pam-0.80-13-src.rpm (Fedora Development Sources).

Embarassing bash

About three month ago I've discovered an interesting way to render bash shell unusable. Consider the following very simple bash script:

for i in 1 2 3; do
return
done

Put this script in the file, say, sourceme. Next, if you do the following:

#> source source
#> sleep 10

... Now hit CTRL-Z to suspend the sleep ...
At this point, the shell starts to behave very strangely. Lets just say that ls /tmp (or anything else) does not show anything.

I've send the message to bash-bug mailing list, reporting the problem to X, but there was no a single reply.

Update 23.11.2005:
bash guys have finally replied, saying that the bug has been confirmed and will be fixed in release 3.1.