Date: Fri, 3 Apr 1998 14:17:40 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Narvi <narvi@haldjas.folklore.ee> Cc: Charles Quarri <randy@hackerz.org>, stable@FreeBSD.ORG Subject: Re: Hesiod support on 2.2 Message-ID: <Pine.BSF.3.96.980403140944.21311b-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.3.96.980403080839.22317K-100000@haldjas.folklore.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Apr 1998, Narvi wrote: > > I was under the impression that Hesiod did not require w/ps/etc to be > > recompiled due to toehold, or was that an MIT-only thing? I thought they > > I have not seen toehold anywhere... And somewho w, ps, ls, etc. have to be > told to talk to hesiod to get the uid<->name mappings. Well, toehold would install all relevant mappings in /etc/passwd, and then w/ps/ls just use the standard getpwent-style calls to access the data. > > dynamically allocated UIDs when the user logged in (this was the toehold > > step), and added them to passwd, etc. They also had a magic NFS that > > converted UIDs to Kerberos identities. The identity information would be > > pulled out of the HS-class DNS records and used to synthesize a local > > account. At least, this is what I heard via Derrick Brashear > > <shadow@andrew.cmu.edu>. :) > > And this all would certainly be hyper cool. But I doubt this all is > available in the hesiod distribution. It sounded fairly spiffy to me. The only mention I have found of toehold in the standard Kerberos release is in KERBEROS(1) where it indicates that a ticket might be provided by toehold or by kinit. One could thing that could be done with PAM (if we had PAM or friends) would be to have the PAM module dynamically create the account as described and perform the toehold activities of choice. Indeed, I also doubt that it is in the standard Hesiod system :). I have not looked at the hesiod distribution recently -- I'll grab a copy this afternoon and take a look. Some have suggested using LDAP for distributing this kind of information, but I personally like the idea of DNS used in this manner -- with security, this becomes quite feasible. There is significant oposition to storing this kind of information in DNS in a number of the groups working with DNS. The feeling is that another service should be used for this. I'm caught between agreeing that this may be beyond the scope of DNS, and also noting that DNS provides an excellent distribution mechanism, with security, etc, for this information. Given that DNSsec provides an excellent public key distribution system, I lean towards storing authentication-related data there. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980403140944.21311b-100000>