Date: Mon, 16 Aug 1999 09:51:30 -0700 (PDT) From: David Wolfskill <dhw@whistle.com> To: kris@hub.freebsd.org, nsayer@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Whither makefiles for src/crypto/telnet/* ? Message-ID: <199908161651.JAA51849@pau-amma.whistle.com> In-Reply-To: <Pine.BSF.4.10.9908141412020.45940-100000@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>Date: Sat, 14 Aug 1999 14:35:34 -0700 (PDT)
>From: Kris Kennaway <kris@hub.freebsd.org>
>I also have prototype code which can store multiple password hashes in the
>password file, and retrieves "secondaries" in a new field in struct
>passwd. You could conceivably set it up to keep a DES password in sync
>with the SRP one, and distribute only the DES over NIS. I don't know how
>extensible NIS is, but maybe we could hide the other hashes in there as
>well for those who understand them.
I'm hardly an "expert" with NIS, but it is actually fairly flexible...
as long as changes imposed are on its own terms. :-)
For example, you can easily create a new NIS "map" (as was done with the
master.passwd.by{name,uid} maps). However, systems that don't know to
look anything up in such a construct will not pay attention to it.
(For example, a Solaris system hasn't a clue that the map
master.passwd.byname exists, much less that it shoudl be used for
anything, so "login" on such a system ignores that map and tries to do
password verification using the passwd.byname map. If the NIS master
server is a FreeBSD box, by default the passwd.byname map merely has "*"
as the encrypted password, while placing the encrypted password in
master.passwd.byname. This is why it's necessary, in such a situation,
to set the "UNSECURE" flag -- that way, the FreeBSD box will place the
encrypted password in passwd.byname, which placates the Solaris box(en).
On a FreeBSD system, there are special checks to see if the process
accessing the master.passwd.by{name,uid} maps has an euid of 0; if so,
the access is permitted; if not, it isn't. But the Solaris box, since
it never knew about the map, certainly doesn't treat it specially, so
though there's no code to access it to make any decisions, J. Random
User is quite able to do (say) a "ypcat -k master.passwd.byname" from
the Solaris box.)
In an (arguably) similar vein, it is possible to use (new) NIS maps to
hold (say) amd maps. (We do this here.) One merely needs to add the
appropriate stanza(s) to the /var/yp/Makefile, and be sure that there is
code in the appropriate places to go look for information in the NIS
maps in question to the /var/yp/Makefile, and be sure that there is
code in the appropriate places to go look for information in the NIS
maps in question.
So you could create new NIS maps to hold nearly any (textual) key/value
pairs you feel like creating. (Unique keys for a given map would make
this easier.)
Whether or not actually using such a mechanism for decision-making is a
Good Idea(tm) is a rather different issue, though (and is likely to be
implementation (among other things) -dependent).
Hope someone finds a bit of this of use,
david
--
David Wolfskill dhw@whistle.com UNIX System Administrator
voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908161651.JAA51849>