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.