Bug#563987: /lib/libnss_hesiod.so.2: hesiod users not fully supported
Ken Raeburn a écrit :
> Aurelien Jarno wrote:
>> 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.
>>
>
> 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?
Wouldn't it be possible to also use Kerberos for shadow information, as
it is actually where the encrypted passwords are stored?
>> IMHO, that's a wrong assumption that should be fixed in pam
> 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....
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 GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: