From owner-freebsd-current Wed Nov 17 8:43:20 1999 Delivered-To: freebsd-current@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 1184614DFC for ; Wed, 17 Nov 1999 08:43:10 -0800 (PST) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id IAA79811 for freebsd-current@FreeBSD.ORG; Wed, 17 Nov 1999 08:43:07 -0800 (PST) Date: Wed, 17 Nov 1999 08:43:07 -0800 (PST) From: David Wolfskill Message-Id: <199911171643.IAA79811@pau-amma.whistle.com> To: freebsd-current@FreeBSD.ORG Subject: Re: "man" reads /etc/rc.conf? In-Reply-To: <199911101357.OAA24746@dorifer.heim3.tu-clausthal.de> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Other folks may also have expressed similar sentiments, but I'll quote a couple that I noted as I was blitzing through my >1900-message backlog (after being in class all last week): >Date: Wed, 10 Nov 1999 14:57:15 +0100 (CET) >From: Oliver Fromme >Using command substitution in /etc/rc.conf{,.local} is NOT >officially supported. I think it should have always been >clear that there should _only_ be plain variable assignments. >That's probably just because you never know which programs >try to read them. >Date: Thu, 11 Nov 1999 00:34:36 +0900 >From: "Daniel C. Sobral" >Calling programs from any of the rc.conf files is considered evil >and it's looked down on. Hmmm.... Reason this is of concern to me isn't apropos or dialup passwords, but because of something I put together last year, a version of which was committed, that affected rc.network (1.23 & 1.32) and rc.conf (1.46 -- later, rc.conf was moved to defaults/rc.conf) (PRs conf/6387 & misc/7435; date on the latter was late July, 1998). I did the original work in a FreeBSD 2.2.5+ environment; little has changed in that area since. Here's the relevant code as of 3.3-R: geddy[2] grep amd_map defaults/rc.conf amd_map_program="NO" # Can be set to "ypcat -k amd.master" geddy[3] grep -1 amd rc.network if [ "X${amd_enable}" = X"YES" ]; then echo -n ' amd' if [ "X${amd_map_program}" != X"NO" ]; then amd_flags="${amd_flags} `eval ${amd_map_program}`" fi if [ -n "$amd_flags" ] then amd -p ${amd_flags} > /var/run/amd.pid 2> /dev/null else amd 2> /dev/null fi In particular, please note the `eval ${amd_map_program}` construct in the above, and that I do set amd_map_program="ypcat -k amd.master" in /etc/rc.conf.local around here. Now, as the original PR (conf/6387) indicates, the intent was to allow amd initialization in a FreeBSD environment where NIS is used to be able to make use of the technique in Jan-Simon Pendry's paper. More specifically, use of the technique permits the amd "master map" -- the construct that specifies which mount points will be managed by amd -- to be specified via NIS. (I'm not a big fan of NIS, but it has its uses.) Now, unless I'm misunderstanding what folks are saying, this change (which has been in 3.x since Septmeber, 1998) is considered -- by some, at least -- to be A Bad Thing. So I ask: if this is so, how would you accomplish the desired result? As noted in that original PR, /etc/{defaults/,}rc.conf{,.local} is sourced (by /etc/rc) well before rc.network is fired up, so there's no way to get the result of "ypcat -k amd.master" until after rc.network has at least got some minimal network functionality up and running. And as I was typing this, a perverse abuse of the FreeBSD NIS implementation just came to mind (for dealing with the dialup password issue): Shove that plain-text password in the master.password file for some (otherwise bogus) login entry. Distribute this via NIS. The password will then be available to clients that are able to ask for the master.password.byname map -- in the FreeBSD implementation, that's euid 0 processes. I don't claim that this is elegant.... :-} Cheers, 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-current" in the body of the message