Bug 188943 - somehow pam fails with custom kernel
somehow pam fails with custom kernel
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
5
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-13 16:22 EDT by Piergiorgio Sartor
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-06 10:02:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Config file of custom kernel (35.27 KB, application/octet-stream)
2006-04-13 16:22 EDT, Piergiorgio Sartor
no flags Details

  None (edit)
Description Piergiorgio Sartor 2006-04-13 16:22:53 EDT
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.
Comment 1 Piergiorgio Sartor 2006-04-13 16:22:54 EDT
Created attachment 127723 [details]
Config file of custom kernel
Comment 2 Tomas Mraz 2006-04-13 16:54:49 EDT
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.
Comment 3 Piergiorgio Sartor 2006-04-13 17:59:18 EDT
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.
Comment 4 Piergiorgio Sartor 2006-05-02 16:03:55 EDT
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.
Comment 6 Steve Grubb 2006-05-03 08:56:00 EDT
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.
Comment 7 Tomas Mraz 2006-05-03 10:28:42 EDT
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.
Comment 8 Piergiorgio Sartor 2006-05-03 14:28:54 EDT
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.
Comment 9 Steve Grubb 2006-05-03 14:46:53 EDT
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.
Comment 10 Piergiorgio Sartor 2006-05-03 15:06:04 EDT
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 ;-)
Comment 11 Tomas Mraz 2006-05-03 15:58:52 EDT
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.
Comment 12 Piergiorgio Sartor 2006-05-03 16:57:16 EDT
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.
Comment 13 Tomas Mraz 2007-02-06 10:02:27 EST
Fixed in upstream PAM CVS.

Note You need to log in before you can comment on or make changes to this bug.