Ive been trying to get pam_console to work for a while, but it always ignored my /etc/security/console.perms file. I have isolated the problem down to the function check_console_name in /var/tmp/portage/pam-0.75-r7/work/Linux-PAM-0.75/modules/pam_console/config.y. This function is calling check_one_console_name with 'consolename', the name of the current login tty, as the first parameter. This is a string that starts /dev/. The second parameter is a range of console regular expressions loaded from the console.perms file. None of them start /dev/, so check_one_console_name never returns true. As a workaround I can add /dev/vc/[0-9][0-9]* to the end of the <console>= line in console.perms. My whole console.perms line looks like: <console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] /dev/vc/[0-9][0-9]* I have not checked the RedHat sources to see what they do different. this is all with ebuild version 0.75-r7
Hmm, thanks for this info... Azarah, should we tack on the additional /dev/vc/[0-9][0-9]* snip to the console= line in console.perms? I guess it sounds like a proper fix. /etc/security/console.perms looks to be exactly as distributed in the $WORKDIR, so it doesnt look like a build problem per se. But who knows :) Whaddaya think?
Ive never seen the /dev/ prefix in console.perms before. Checking though the redhat documentation I see they use it for serial consoles. Im not sure what magic means they can omit the /dev/ prefix from /dev/tty0, but not /dev/ttyS0
Using KDE ? if so, the KDE /etc/pam.d/ files do not use system-auth. Did you try it yet at a console ? Also update pam, as there went some needed fixes in (or just remerge for fun =) ).
yes, I am using kde. I am aware that there is a different reason why pam_console doesnt work if you log in using kdm yes, this issue is definitely just relating to text console logins yes, my pam is current
Hi, and sorry. I must confess that I did not read this properly :-) As for the real fix, this keeps coming up from time to time, but I keep on forgetting to fix it. Problem comes into using devfsd ... For this to work, you need to add to /etc/devfsd.conf, and then restart devfsd (killall -HUP devfsd): # Uncomment this to let PAM manage devfs REGISTER .* CFUNCTION /lib/security/pam_console_apply_devfsd.so pam_console_apply_single $devpath
Created attachment 3236 [details] /etc/devfsd.conf Just to clarify that the section that should be added consists only of two lines (the comment, and the devfsd.conf entry), I added my devfsd.conf.
Erm, to maybe expand a bit ... console.perms needs to be applied ... this is where pam_console_apply_devfsd.so comes into play. I cannot remember the full issue behind this, but if need be ill look it up again.
> For this to work, you need to add to /etc/devfsd.conf, and then > restart devfsd (killall -HUP devfsd): > # Uncomment this to let PAM manage devfs > REGISTER .* CFUNCTION > /lib/security/pam_console_apply_devfsd.so > pam_console_apply_single $devpath No, thats a different issue. When a user logs in on a local console, pam_console tweaks some permissions on some files and records that user name in a lock file. pam_console_apply_devfsd is needed so that the permissions can be correctly tweaked when devfs dynamically creates a device when a user is already logged in on a local console. pam_console_apply_devfsd is implemented by checking that lock file (the one created by pam_console at login) and is completely independant of this problem. This issue is about which tty names pam_console considers to be 'local consoles' at the point when a user logs in. Currently pam does not consider the /dev/vc/0 ttys to be local consoles. Therefore it doesnt invoke the permissions tweaks, and doesnt create the lock file used by pam_console_apply_devfsd.
So do we want to add the proposed config clause that's being suggested here?
I would like to know why the workaround is needed before recommending adding it to the standard config file.
Ok, got the problem. Seems like pam-login sets PAM_TTY to the fully qualified filename of the tty, which then borks check_console_name(). I hacked pam-0.75-pam_console-fix-fullpath-in-file-classes.patch, which should hopefully resolve this. Tests ok this side. This should be fixed in pam-0.75-r8.
Created attachment 4654 [details, diff] pam-0.75-pam_console-fix-fullpath-in-file-classes.patch Patch that "fixes" this problem.
That patch looks basically sound. I think the last if (check_one_console_name(consolename, c->name)) { should be if (check_one_console_name(consolename, full_path)) { > pam-login sets PAM_TTY to the fully qualified filename of the tty Note that the pam documentation (/usr/share/doc/pam-0.75-r7/txt/pam_appl.txt.gz) requires this.
Hmm, you are correct .. only slept 4 hours in the last 24 .. what can I say =). Will fix the patch asap. As for the PAM_TTY .. not sure if the propragated from login shadow side, or util-linux side, but I am guessing if Redhat/Mandrake use it without problems, then their login do not follow PAM spec.
Created attachment 4662 [details, diff] pam-0.75-pam_console-fix-fullpath-in-file-classes.patch Should be the proper one.
