On Sat, 2005-06-18 at 05:50 -0700, Steve G wrote: > The kernel switch we are using is CONFIG_AUDITSYSCALL. However, you should be > able to login without it. It does depend on which version of audit-libs and pam > that you are using. If you are using the current versions of each (rawhide), you > shouldn't be having a problem. thanks for the explanation checked, the kernel (now vanilla 2.6.12 final) uses CONFIG_AUDITSYSCALL. also i'm using the latest rawhide versions of today, with pam-0.79-10 audit-0.9.7-1 audit-libs-0.9.7-1 and still can't login. (downgrading to the fc4 versions of audit & audit-libs works ok) > Some pam configurations have also been updated to call pam_loginuid.so. What this > does is set a new process attribute, loginuid, that is inheritted by all > processes after login forks to start your shell. This way, if you su to root, we > can see that you originally logged in under another account. There was a bug > spotted a week ago that pam_loginuid.so was not checking for ENOENT when it tried > to open /proc/self/loginuid to set that process attribute. This could also > prevent you from logging in, too. > > To check this, comment out pam_loginuid.so in /etc/pam.d/login,sshd,gdm. Or you > can change it from required to optional. checked the files login, sshd, gdm in /etc/pam.d/ but there is no pam_loginuid.so line in these files for me. (?) > Today should have audit-libs-0.9.8 in rawhide, which cleans up a couple more user > space audit message functions that are not called by pam. If you could check to > see if loginuid is causing the problem that would help. Any other debug info > would help too. maybe my problem is that i'm not using selinux (because of reiserfs) ? what log/info is needed to help debug this? if it's not a trivial thing (selinux maybe) i think it's better to put this to bugzilla. thanks -- Lars G <terraformers@xxxxxxxxx>