We've found that since updating to lenny, cron jobs for normal,
non-local users (who are listed in hesiod) aren't being run.  Adding
entries to /etc/shadow works around it.  The following message gets
logged, and the cron job just never runs:

Jan  6 16:07:01 just-testing CRON[25360]: Authentication service cannot retrieve authentication info

Chasing things a bit further, cron uses pam, and pam is looking up
shadow password entries.  (For some reason, this problem doesn't bite
us with ssh or X login, just cron, so far as we've noticed.)  The
above error message comes from the pam code.

The pam code seems to assume that shadow password entries will exist
for any valid account.  We're using libnss_hesiod, and it doesn't
support the shadow-password lookups, just regular password lookups.

A simple test program (that requires a libnss_hesiod setup to
demonstrate):

    #include <shadow.h>
    #include <stdio.h>
    #include <stdlib.h>
    int main () {
      struct spwd *sp = getspnam("nightly");
      if (sp) { printf("win\n"); exit(0); } else { printf("fail\n"); exit(1); }
    }

I expect the pam code's assumption is probably reasonable; if so, then
libnss_hesiod should be filling in the gap, and we should just be able
to use "shadow: files hesiod" in nsswitch.conf.

hesiod is not supposed to be used to provide password. Even if used that
way, I don't really see the point of providing a shadow database though
hesiod, as the data will anyway be public, as published in the DNS.

IMHO, that's a wrong assumption that should be fixed in pam.

Ken Raeburn a écrit :

Wouldn't it be possible to also use Kerberos for shadow information, as
it is actually where the encrypted passwords are stored?

Other nsswitch modules provide both interfaces, because there is
actually a shadow database. Hesiod does not provide a shadow database.

The only thing that can be done is to provide functions that will always
return an error. Not sure it is really useful.

Aurelien Jarno wrote:

Kerberos doesn't necessarily have the information in its database, and
the protocol provides no way to pass the information around.
If that's the model -- that it's permissible for there not to be shadow
data -- then yes, the Hesiod code is okay and this is a pam bug...

Ken

Aurelien Jarno wrote:

Certainly not password authentication data, but it can be (and is) used
for the other /etc/passwd info (say, in combination with Kerberos
authentication; they both came out of MIT's Project Athena).  But on the
systems it was developed on, some of the shadow information (the hashed
password) wasn't in a separate shadow file, and some of it just didn't
exist.  So maybe Hesiod's interface is just outdated?
That was my other thought, but at first glance, it appeared that other
nsswitch modules provided both together.  And I've seen cases on other
systems where the shadow entry was required for things to work; not that
that necessarily means they weren't broken too....

Ken

Ken Raeburn a écrit :

It's permissible, but as said not really useful. That won't change the
value returned by getspnam(), which already return -1 when an entry is
not found. This returned value simply means that shadow entry exists for
the given name.

(Sorry to revisit such an old bug, but we keep running into it now and
then...)

If this is deemed to be a PAM bug, can this bug report just be re-tagged
as a PAM bug and reassigned to the appropriate party?

The high-level problem -- cron doesn't work for Kerberos/Hesiod users
unless you manually add /etc/shadow entries -- seems pretty clearly like
a bug to me, regardless of which package is eventually deemed at fault.

Ken