man.cgi in "online" mode

[Kristaps Dzonsons <kristaps@bsd.lv>]

Hi,

If you're looking at commits and tech@ messages, you'll notice a lot of 
work in apropos(1) and mandocdb(8).  What's not mentioned much is 
man.cgi, which is similar to existing man.cgi scripts but with the power 
of our apropos(1) and mandoc(1) as a renderer.

To date, I've designed man.cgi to run in "secure" and "insecure" mode. 
"Insecure" mode is for non-jailed CGI processes, scanning the system's 
mandocdb(8) (like apropos(1)) and formatting output with mandoc(1).  The 
"secure" mode uses mandocdb(8) databases and a cache of pre-formatted 
manpages, both kept fresh with the new-born manup(8) utility.  One 
triggers insecure mode by passing the $INSECURE variable to the CGI script.

The question is as follows: is an "insecure" mode reasonable?  It's a 
security risk to allow a CGI to fork()/exec() at all, which makes it 
unlikely for public-facing servers.  But it's a hassle to set up and 
maintain a server just for internal manpages.  And do manuals really 
change so much that on-line rendering is necessary?  The "secure" mode 
cache is freshened with a single command invocation, only updating 
what's out of date (quickly, at that).

My thought is to write a Firefox add-in to do this instead, but it seems 
that somebody in discuss@-land may have a better idea.  Or better yet, 
might think this idea awesome enough to do on their own -- all the code 
to interact with mandocdb(8) is already in man.cgi (cgi.c).  The 
benefits are that it kicks some complexity out of man.cgi and lets me 
focus more on a single purpose, instead of spreading out over two.

Of course, this limits to Firefox.  I happen to despise Firefox, but am 
not sure if other solutions beyond a standalone daemon like cupsd.

Thoughts?

Take care,

Kristaps
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv