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       

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Reply via email to