Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Mar 2002 08:58:14 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Luigi Rizzo <luigi@FreeBSD.org>
Cc:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/nfsclient bootp_subr.c
Message-ID:  <Pine.NEB.3.96L.1020313085311.36618L-100000@fledge.watson.org>
In-Reply-To: <20020313054705.B65383@iguana.icir.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 13 Mar 2002, Luigi Rizzo wrote:

> On Wed, Mar 13, 2002 at 08:05:59AM -0500, Robert Watson wrote:
> ...
> > Hmm.  This is in the private number range, I assume?  Hopefully the
> 
> of course yes.
> 
> > handling is sufficiently robust that whatever comes back, bad things won't
> > happen (be it a binary blob with lots of nulls, *'s, shell
> > meta-characters, etc, when handled in userland?).
> 
> I am not going, in the kernel, to escape characters which have special
> meaning for arbitrary userland programs -- that's their business. 
> 
> The kernel copies chars up to the first NUL and within the buffer size
> allocated for the purpose, and bootpc_tag() makes sure that there is
> actually a NUL in the source buffer when it returns. 

I was wondering if the better approach wouldn't be to export the data as
SYSCTL_OPAQUE, since it really is just a binary blob.  Otherwise it will
pop out in sysctl -a (if represented as a string) and potential toast the
terminal.  I had no end of fun sending xterm resize and retitle escape
codes during IETF a few years ago in Pittsburgh...  Turns out everyone ran
dsniff in an xterm without output filtering.  For the general exporting
case (see below), exporting is also more useful.

> > It seems to me that a slightly more useful incantation would actually
> > expose all of the bootp options to userland via a more dimmensional sysctl
> > mib.  This would allow userland to inspect any other options that turned
> 
> Sure, i don't mind doing that using dynamic sysctls if people have no
> objections.  I can create kern.bootp.tX (where X is the tag number)
> sysctl variables according to what came back from the server.  Using
> names instead of numeric values is not going to work I am afraid, as
> half of the namespace is not standardized anyways. 

Sounds great.  I was also interested in, for reference purposes, caching
and exporting the interface name used to bootp (caching in case it's
removed, since the ifnet will go away).  What I have in mind is a userland
utility to make use of the bootp options more generally following a
diskless boot.  I'm particularly interested in the bootp DNS-related
fields, log server, and YP information fields.  A lot of this would remove
the local customization I have to do for rc.conf and /etc.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020313085311.36618L-100000>