[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#563987: /lib/libnss_hesiod.so.2: hesiod users not fully supported



On Wed, Jan 06, 2010 at 04:24:04PM -0500, Ken Raeburn wrote:
> Package: libc6
> Version: 2.7-18
> Severity: normal
> File: /lib/libnss_hesiod.so.2
> 
> 
> 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.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net



Reply to: