i think gentoo missed the fact that a second pam service (kde-np by default) is now needed for autologin. the normal installation process handles this.

alternatively, kde-np exists, but plainly does not work. if so, please mail me /etc/pam.d/kde-np. read the auth.*/authpriv.* and daemon.* syslog facilities' output.

Hi Oswald, thanks for your reply. The needed second pam service (/etc/pam.d/kde-np) is indeed not available in Gentoo. I have created a bugreport on bugs.gentoo.org (http://bugs.gentoo.org/show_bug.cgi?id=33690)

Should /etc/pam.d/kde-np have the same pam permissions as /etc/pam.d/kde by default?


#%PAM-1.0

auth       required     /lib/security/pam_stack.so service=system-auth
auth       required     /lib/security/pam_nologin.so

account    required     /lib/security/pam_stack.so service=system-auth

password   required     /lib/security/pam_stack.so service=system-auth

session    required     /lib/security/pam_stack.so service=system-auth

session    optional     /lib/security/pam_console.so

no, obviously it has to allow password-less login. simply prepending
auth sufficient pam_permit.so
to the service is theoretically sufficient, even though not exactly perfect. look at kdebase/mkpamserv to see which services i declared allowed (the list is certainly not exhaustive, but i lost my crystal ball :}). basically anything that does not require some authentication token (password) is ok.

in any case i close this as a packaging bug.

Based on my understanding of this bug and running the mkpamserv script, I am adding a "kde-np" with the following permissions:

#%PAM-1.0

auth       required     /lib/security/pam_nologin.so
auth       required     /lib/security/pam_permit.so
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth
session    optional     /lib/security/pam_console.so

that should be ok

*** Bug 70547 has been marked as a duplicate of this bug. ***

*** Bug 71212 has been marked as a duplicate of this bug. ***

*** Bug 74084 has been marked as a duplicate of this bug. ***

*** Bug 74200 has been marked as a duplicate of this bug. ***

Since this bug has been diagnosed, it would be very helpful if someone provided a recipe for a workaround that does not require an intimate knowledge of pam, until the fix has been applied where necessary.  

See my comment #5 for what you can do as a workaround.

cd /etc/pam.d
(echo "auth sufficient pam_permit.so"; cat kde) > kde-np

see comment #4

The command lines in #13 don't quite work:

suillus:/etc/pam.d # (echo "auth sufficient pam_permit.so"; cat kde) > kde-np
cat: kde: No such file or directory

In any event, is it sufficient to type just those lines (after amendment) or is it necessary to include additional lines from #5?  Please, in your reply don't assume any knowledge of pam (since the original problem is very visible at the user level).

> cat: kde: No such file or directory 
> 
then use the service your kdm was configured with (--with-pam or --with-kdm-pam). maybe it's "kdm" or maybe even "xdm".

i can't say anything better. the packagers screwed up, and that's it. if you installed from source, you wouldn't have the problem.

i wish the packagers would read the ChangeLog i maintain for exactly this type of changes.

In my case it was xdm, which I found by doing an ls on the pam.d directory.  But merely creating the kde-np file in pam.d didn't enable the passwordless login.  Is there something else that needs to be done to activate the kde-np file?

if the primary service is "xdm", then the password-less one is of course  "xdm-np".

Your suggestion in #17 did the trick.  For the benefit of others who are following this conversation, here's my take on the recipe:

1. Look in the directory /etc/pam.d for files named "kde", "xdm", or "kdm".

2. Assuming you find the file "kde", do the following:

cd /etc/pam.d 
 (echo "auth sufficient pam_permit.so"; cat kde) > kde-np 

If instead you find "xdm" or "kdm", replace "kde" by one of those in two places in the second line above.

I note that solving this problem exposed another one, already reported: if both automatic login and password-less login are activated, the keymappings don't work properly on auto-login: the Win key is not recognized.  Doing a normal login, with or without password, is the workaround.
 

I look forward to trying the workaround, however I'd like to note (for the record and all that) that this also occured with the Mandrake 9.2 packages.  I will notify Mandrake's bug-wranglers about it.

Similar problem with SuSE 9.0 pacakages.  Log reports that winbind failed, kdm reports auth failed.  

The long discussion does not, unfortunately, answer a simple question -- why is all these gymnastics necessary? Why is not kdm simply looking inside pam.d/kde?..

Why does the GUI allow one to configure the list of no-password users without a hint of warning?

> why is all these gymnastics necessary?
> 
because otherwise it will crash with certain configurations.

> Why does the GUI allow one to configure the list of no-password users
> without a hint of warning?
>
because under normal circumstances the installation process configures
it correctly. it's counterproductive to take care of every possible
external breakage.

I did as the correction above suggested, but I still get no password-less login. I don't get any kind of error message at startup but I have the same problem as described above. 
I am using kde 3.2.2 and FC3, a brand new installation.

Here is what shows up in /var/log/messages.


Jan 18 10:43:34 localhost gdm(pam_unix)[4835]: authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=  user=boisvert

thanks.