Visibility of VCL source (Was: Re: [PATCH] vcl.show expand includes)

[Poul-Henning Kamp]

In message <CAEh05Va0upueb8CDQEdNh=NXhpf_=rZ1iTfr5EKzrR9tFyi9Hw at mail.gmail.com>
, Dag Haavi Finstad writes:

>As discussed on the Stockholm VDD, here's a proposal for #1457.
>[...]
>The VCLs are output in the same order as they appear in the VCL
>location/profiling table in the compiled VCL (the vcl->ref stuff used
>in the VCL_trace records), so if someone wanted to do a VCL code
>tracer thing, that should be possible.

I'm not at all happy with the fact that we still dlopen() VCL's for
vcl.show().  That exposes the master process in ways I don't like,
even more so now we have VMODS which pull in strange libraries.

One way to fix it is to accept that we cannot show the source
unless the child process is running.  I can live with that.

If that is not acceptable, we could fork a child of master to
dlopen() the compiled VCL (we already do that for testing) and
pull the source out of that.

But all in all I prefer to make the child responsible, so that
we don't dlopen() compiled VCL's unnecessarily.

If we go that route, we can do as now, and only exposed it via
VCL or we can expose the counters and VCL source via VSM to
avoid the VCL overhead.

The latter is probably best for interactive visuals, but does
expose the VCL source without CLI auth check.  I'm not sure
if that is OK.

Input ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.