I did some troubleshooting of this problem with an empty /etc/pmount.allow file. Running pmount -d I was able to find the problem (output truncated for brevity):
~ $ pmount -d -t ext2 /dev/sdc1
resolved /dev/sdc1 to device /dev/sdc1
mount point to be used: /media/sdc1
no iocharset given, current locale encoding is UTF-8
locale encoding uses UTF-8, setting iocharset to 'utf8'
Cleaning lock directory /var/lock/pmount_dev_sdc1
device_whitelist: checking /etc/pmount.allow...
device_whitlisted(): nothing matched, returning 0
find_sysfs_device: looking for sysfs directory for device 8:145
find_sysfs_device: checking whether /dev/sdc1 is on /sys/block/ram0 (1:0)
find_sysfs_device: checking whether /dev/sdc1 is on /sys/block/sdc (8:144)
find_sysfs_device: major device numbers match
find_sysfs_device: minor device numbers do not match, checking partitions...
find_sysfs_device: checking whether device /dev/sdc1 matches partition 8:144
find_sysfs_device: checking whether device /dev/sdc1 matches partition 8:145
find_sysfs_device: -> partition matches, belongs to block device /sys/block/sdc
device_removable: could not find a sysfs device for /dev/sdc1
Error: device /dev/sdc1 is not removable
policy check failed
pmount finds a matching block device for /dev/sdc1, but there isn't enough information in /sys/block/ for it to proceed. Instead of checking the removable flag of the matching hardware block device (/sys/block/sdc/removable) it needs to check the flag of the specific partition (/sys/block/sdc1/removable) which fails because the directory /sys/block/sdc1/ does not exist.
This behavior has changed in the latest unstable version (0.9.19). pmount now looks in /sys/class/block/ for matching device nodes which, on my system, contains directories for individual partitions on SCSI devices. I don't know how you feel about running testing, but it does seem to fix the problem.
Getting pmount to behave the way it's supposed to and allow mounting of all suitable devices that have /sys/class/block/<device>/removable set to 1 is comparable to having the line /dev/sd[a-z][1-99] set in /etc/pmount.allow. Any removable USB storage media become mountable by the user, which is by design. It's also what allows PAM_USB to authenticate from unmounted media. Run pamusb-check --debug me to see how PAM_USB calls pmount. There are some things you can try to help prevent unsafe mounts while still allowing PAM_USB and pmount to work as intended.
You can make sure that no services will automatically mount inserted media insecurely. Essentially, you would have to tell your ssytem that a disk is trusted by manually mounting it or having an authorized service mount it in the background. For instance, PAM_USB matches the UUID of the inserted device with the devices listed in its configuration file, which ensures that it only tries to mount trusted devices.
You can remove other users from the plugdev group, since only members of plugdev can use pmount. Of course, since PAM_USB calls pmount with the credentials of the user trying to authenticate, users of PAM_USB must be in the plugdev group. So, this measure won't work if there are other users on your system whom you want to be able to log in with PAM_USB, but you don't trust them to only insert safe media.
Also, it might be possible to use pamusb-agent to turn on your system's password check for inserted USB devices automatically upon unlocking. I'm not sure how that would affect further attempts to authenticate with PAM_USB, or if it can even be done, but it might be worth fiddling with the idea.
Fare thee well!
A quick test revealed that this is only the case after the user has been authenticated. When logging in, PAM_USB is able to mount the media regardless of the user's membership in the plugdev group. That makes sense, since PAM_USB cannot run anything as user until that user is authenticated and it must run pmount before it can authenticate.
Of course, since PAM_USB
with the credentials of the user trying to authenticate, users of PAM_USB
must be in the plugdev