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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
