Description of problem: I upgraded a PC from FC4 to FC5 and I installed a custom kernel (config attached), some latest 2.6.16.2. I know that they're already at .5, but from the changelog I do not think there is something interesting there. After that, login with ssh, while working fine, results in a pam error reported in /var/log/secure. Also crond causes a pam error: crond[...]: pam_loginuid(crond:session): set_loginuid failed opening loginuid Version-Release number of selected component (if applicable): pam-0.99.3.0-2 How reproducible: I seems always Steps to Reproduce: 1. Upgrade from FC4 to FC5 (maybe important) 2. Install a custom kernel, probably without some important feature. 3. Login using ssh (sshd is installed and running, of course) Actual results: Among all, /var/log/secure shows this line: sshd[...]: pam_loginuid(sshd:session): set_loginuid failed opening loginuid Expected results: Some other info, like: ... pam_unix(sshd:session): session opened for user ... But no failure. Additional info: kernel 2.6.16-1.2080_FC5, standard, does not show the problem. I tried to boot this kernel with "selinux=0", in order to try if this could be difference (custom kernel does not have selinux), but the 1.2080 worked fine as before, i.e. to "failed" message. I did not try to login directly on console, this PC does not have monitor and I'm managing it remotely. I had a quick look into the pam docs, but I could not find any reference to kernel requirements, maybe it would be enough to add some info on what is required from the kernel in order to support pam without errors. I did not try to recompile the FC5 kernel with custom config.
Created attachment 127723 [details] Config file of custom kernel
You must either enable CONFIG_AUDITSYSCALL or remove pam_loginuid.so from all files in /etc/pam.d/ I don't know when existence of /proc/self/loginuid started to depend on this config option however apparently it now does.
Sorry to bother you again, but maybe it would be better to check for /proc/self/loginuid before reporting the failure? I think same concept is already in place for selinux, or not? Thanks.
Well, sorry again, but I had the impression I need to re-open it in order to understand if a "fix" is possible. Maybe pam should check if /proc/self/loginuid exists before trying to use it. What I want to say is that it could be good to provide a component, pam in this case, which is reasonably robust to kernel configuration changes. Thanks again.
I trimmed the code to the important pieces: int fd, count, rc = 0; fd = open("/proc/self/loginuid", O_NOFOLLOW|O_WRONLY|O_TRUNC); if (fd < 0) { int loglevel = LOG_DEBUG; if (errno != ENOENT) { rc = 1; loglevel = LOG_ERR; } pam_syslog(pamh, loglevel, "set_loginuid failed opening loginuid"); return rc; } From the code above, the login failed message should have debug level output. Is this the case? I suppose it would be better to move the pam_syslog call inside the if (errno != ENOENT) statement where the loglevel gets set. This would let us get rid of the LOG_DEBUG assignment, too. But before we do that, we should make sure LOG_DEBUG really goes out when only when debug is set.
OK, from the original report I actually thought that the module failed (not that it only reported a DEBUG level syslog message). If the message was reported as ERR and not DEBUG I'd say we should fix that but I don't think that unconditional DEBUG message which appears only with some custom compiled kernels is a bug. Actually it gives you a correct hint that you're losing some functionality.
Well, yes and no. Yes, you get an hint, no you get confused. IMHO there should not be any "failed" something reported, unless I ask explicitly for a different verbosity level. In other words, if I disable audit, I should not get any complains from "pam" unless I ask explicitly (changing the debug level, somehow, or else) to tell me what is not working. The problems of the message are: 1) It's unclear: I do not know how serious it is or if something will not work anymore or which functionality I miss. 2) It's increasing the "noise level" of the syslog. If there is something else really critical, it could go unseen. In general I would not consider this a "bug", much more an "enhancement request": being able to enable/disable this kind of messages, depending on a verbosity level parameter. Side question: should I re-open the debug when replying? This time I'll do, but I'm not sure if this is the correct procedure. Please advise. Thanks.
Tomas, I can see making the code like this: fd = open("/proc/self/loginuid", O_NOFOLLOW|O_WRONLY|O_TRUNC); if (fd < 0) { if (errno != ENOENT) { rc = 1; pam_syslog(pamh, LOG_ERR, "set_loginuid failed opening loginuid"); } return rc; } I think this would be better since the intent was to put it out for debug. At this poing pam_loginuid is working very well so I doubt we'll ever need the message. But for the record, there are getting to be more and more things that use the loginuid, so I'd allow syscall_audit in your kernel. As long as you don't install the audit daemon, you should see next to no change in performance.
Uhm, I esitate to enable things I do not intend to use, unless they are modules, and even in this case not always. The reason being, as you understood, performance. It might be audit has almost no impact, but, you know, enabling this and that with "almost no impact" can lead to some "impact" in the end. Specifically, the PC in question is an old 500MHz machine, so I would like to keep it as light as possible. That's why I used a custom kernel. Since in other circumstances I experienced some measurable improvement in using a custom kernel, I tend to continue in this way. Anyway, I think you got the point, I hope you'll take the right decision ;-)
Well if you optimize this way, you could certainly also remove pam_loginuid from all config files in pam.d which would make authentication faster.
At the moment I see the following possibilities: 1) Ignore the syslog message 2) Enable the audit into the kernel 3) Modify the config files 4) Adapt pam in order to not produce the syslog message Solution 1) is the simplest, even if the syslog could be a little bit noisy. Enabling audit, 2), might be OK, it would interesting to know what is the real impact. 3) While very flexible, could be quite annoying, especially after some update, when a lot of .rpmnew/.rpmsave are eventually left around and need to be checked (if no overwrite occurs). Last one, 4), while being very generic, could increase complexity of pam, I guess. Now, I think I'll try 2), so I have only one point to touch, instead of two or more in case of 3). Please consider 4) as a more comprehensive approach to the issue. Thanks again.
Fixed in upstream PAM CVS.