Karmic Koala, and my best guess is that the problem is in udev, but since I can't find where the initial umask is set for such virtual filesystem parts as this, that's only a guess. KDM will not accept password, so cannot be normally initialized, and dropping to console, after entering user and pw, a couple of screens of "bash: /dev/null: permission denied" precede the prompt. After stopping kdm and startx with sudo, a root, but otherwise normal graphical session suggests the problem is not X. Xsession-errors shows similar /dev/null errors reported in the Xsession script in three places, all attempted references to or related to /dev/null. /dev/null permissions are root only and cannot be changed by the often recommended rm, mknod route, as they immediately revert on boot. People recommend reinstallation, but since this appeared to only be connected to updates installed in April 2010, about the third week, or possibly to the installation of the udftools package, this doesn't seem a viable solution, and certainly not a practical one if recurrence may be expected. What I would like to know is how is the umask set for this, and what must one do to correct the problem in an incisive manner. Thank you for any attention to this.
I still haven't got kdm straightened out, so it is still necessary to use startx to begin a session, but the '/dev/null: permission denied' matter is now resolved. It appears that the '50-udev-