Xscreensaver before 4.15 creates temporary files insecurely in (1) driver/passwd-kerberos.c, (2) driver/xscreensaver-getimage-video, (3) driver/xscreensaver.kss.in, and the (4) vidwhacker and (5) webcollage screensavers, which allows local users to overwrite arbitrary files via a symlink attack.

Xscreensaver 4.14 contains certain debugging code that should have been omitted, which causes Xscreensaver to create temporary files insecurely in the (1) apple2, (2) xanalogtv, and (3) pong screensavers, and allows local users to overwrite arbitrary files via a symlink attack.

rdesktop 1.3.1 with xscreensaver 4.14, and possibly other versions, when running on Fedora and possibly other platforms, does not release the keyboard focus when xscreensaver starts, which causes the password to be entered into the active window when the user unlocks the screen.

Description of problem: xscreensaver has started crashing a few days ago

Version-Release number of selected component (if applicable): xscreensaver-5.03-10.fc7.src.rpm

How reproducible: sometimes

Steps to Reproduce: 1. lock screen 2. leave computer 3. come back and wiggle mouse if screen dark Actual results: screen unlocked without entering password

Expected results: screen remains locked until I enter my password

Additional info: output of "xscreensaver -sync -verbose -no-capture" will be attached. stupidly enough I forgot to up the ulimit -c from 0. it's running in sync and verbose mode again after "ulimit -c 2048". Will update this BZ if it craps out again.

XScreenSaver 4.10, when using a remote directory service for credentials, does not properly handle the results from the getpwuid function in drivers/lock.c when there is no network connectivity, which causes XScreenSaver to crash and unlock the screen and allows local users to bypass authentication.