Re: custom authentication functions

> > The "e" flag to ps on BSD-based boxes will give you the environment.
> > To get it all, you want to use "ww" as well. I don't konw SysV boxes
> Right. I'd claim that's a bug in "ps", not a problem to work around in
> the CGI spec that's not even supposed to be UNIX-specific, actually. :-)

I wouldn't call it a bug in ps; ps's job is to give you information
about a process. That's part of the information. That you've chosen to
put information you'd rather not have public in a public area is a
problem in your design; much like a password changing program that
echos the password to the screen.

CGI needs a unix-specific hook to deal with this problem. On platforms
where the process environment isn't public knowledge - or where the
CGI variables aren't in the process environment - this isn't a
problem.

> I'd hate to see the fact that the only even-mildly-secure-yet-portable IPC
> under UNIX is pipes cause the CGI spec to have some grodiness like
> additional pipes open to the script just to pass "secure" information.

I haven't looked into solutions to this; I haven't needed them. The
only one I vaguely recall tried passing the authentication information
in a second argument (oops), then wind up feeding it to the CGI script
in front of the data.

> > > Fortunately, our webservers don't have any untrusted users logging in.
> > That depends on who you are trying to protect against,
> I'd also hate to see CGI be unusable with some languages just to keep

This problem doesn't require a change in CGI. CGI is for more than
Unix. Unix systems have to find another solution. Ignoring the problem
is one of them.

> I misspoke. I meant server there. I haven't found a server that would
> pass authentication to the CGI script.

At least two used to. They've both since been fixed to not do that to
avoid the security issues above.

	<mike

Received on Friday, 29 March 1996 00:40:55 UTC