On Wed, Nov 18, 1998 at 10:47:13AM +0100, Ralf S. Engelschall wrote:
>
> Here I forward a message from c.i.w.s.u posted yesterday. The poster talks
> about Apache+mod_ssl+mod_frontpage and the fact that SSL works fine, FP works
> fine, but the combination SSL+FP fails because some environment things caused
> by mod_ssl (perhaps the SSL* env vars, whatever) seems to confuse the
> Frontpage stuff.
>
> I know that some other (Jan?) already fiddled around with
> Apache+mod_ssl+mod_frontpage+etc. Perhaps you have some experiences you can
> share with us and the poster.
If fpexe is used to start the fp programs, just remove all "unneeded"
environment variables there or make a wrapper around the "normal" binaries.
If anyone's interested, I've got a modified fpexe program so one can run
fp without the mod_frontpage and instead use the mod_rewrite. That makes
it possible to use suexec which in turn removes the offending environment
variables. See http://bofh.diegeekdie.com/software/hacks/fpse98/)
/Sebastian
>
> -- forwarded message --
> From: "Matthew H. North" <[EMAIL PROTECTED]>
> Newsgroups: comp.infosystems.www.servers.unix
> Subject: Apache1.3.3 + Apache-SSL mod + fp-apache mod
> Date: Tue, 17 Nov 1998 10:44:58 -0800
> Organization: CTS Network Services
> Lines: 86
> Message-ID: <[EMAIL PROTECTED]>
>
> Hello,
>
> We are currently working on integrating our succesful Apache+SSL and
> Apache+FP servers together, to create a hybrid Apache+SSL+FP server.
> We've done this, with the source compiling and binaries running without
> flaw, however, we cannot get FP extension calls to work when called
> through an https: reference. The FP server works fine. The SSL server
> works fine. But, if you're on a page with frontpage content, accessed
> through an https: reference, and you click on one of the FP controls,
> the followin error is returned to the client's browser:
>
> ---
> FrontPage Error.
>
> User: please report details to this site's webmaster.
>
> Webmaster: please see the server's system log for more details.
> ---
>
> No error is reported in the server log. This error is returned by the
> FP extension being called (as we found out through some digging around).
>
> I've done some digging in the Apache+FP+SSL source code, and I managed
> to trace the code to the point where the FP extensions are called by the
> server. Specifically, I've added some debug code to dump the exact exec
> call that's made to call the fpexe suid wrapper (which then calls
> whichever fp extension is needed), and the entire environment variable
> list at the time. I've done this for both successful Apache+FP and
> unsuccessful Apache+FP+SSL. The ONLY differences between the two
> environments are the addition, in the SSL server, of some extra
> environment variables that are SSL specific (HTTPS, HTTPS_CIPHER,
> HTTPS_KEYSIZE, HTTPS_SECRETKEYSIZE, SSL_CIPHER, SSL_PROTOCOL_VERSION,
> SSL_SERVER_C, SSL_SERVER_CN, SSL_SERVER_DN, SSL_SERVER_EMAIL,
> SSL_SERVER_I_C, SSL_SERVER_I_CN, SSL_SERVER_I_DN, SSL_SERVER_I_EMAIL,
> SSL_SERVER_I_O, SSL_SERVER_I_ST, SSL_SERVER_O, SSL_SERVER_ST,
> SSL_SSLEAY_VERSION). These are all passed to fpexe when called through
> SSL, along with all the other normal env vars that are passed to fpexe
> durring a working non-SSL call. So one might come to the conclusion
> that these extra env vars throw up some warning flags in the fp
> extentions themselves.
>
> So, I began looking at the source to the only component of the FP
> extensions that the source is available for, fpexe. It does some
> environment cleanup before calling any extensions, to make the
> environment as secure as possible before calling the required
> extension. If anything doesn't fit, the call is not made. In this
> code, there is a routine that compares the environment to a structure
> containing a set of acceptable environment variables to pass to the
> extension being called. This structure did not contain HTTPS* and SSL_*
> as one might think it would need to. As a result, the extension being
> called was called without any of the HTTPS* or SSL_* env vars passed to
> it. One might think come to the conclusion that this was the source of
> the problem. So, I went ahead and added these env vars to the
> acceptable list, recompiled and tested. No luck. Upon further
> supposition, it follows that if the HTTPS* and SSL_* env vars weren't
> being passed to the extension, AND they constitute the only difference
> between the SSL and non-SSL calls to the extension, that the SSL call
> would be, in effect, identical to to the non-SSL call. If this is the
> case, it should work fine!
>
> Furthermore, I *know* the requested extension *is* being executed
> because the error returned to the client's browser is ONLY contained in
> the shtml.exe executable (which is the extension we've been calling for
> testing purposes). The only way this gets called is if fpexe completes
> its security checks, and continues with the exec of the shtml.exe
> executable. And, to take it one step farther, the shtml.exe that is
> called is acutally a stub executable in the user's web directory. It
> calls a base shtml.exe executable in
> /usr/local/frontpage/currentversion/exes/_vti_bin/shtml.exe. I know the
> stub is calling the base shtml.exe because if the error message returned
> to the client's browser is not contained in the stub executable, but is
> in the base executable.
>
> So, I've come to the conclusion that the shtml.exe extension is seeing
> something in the environment (be it environment variables, lock files,
> whatever), that it doesn't like, and is failing based on that. What I
> need to know is: what is it that it's seeing that's causing it to fail?
>
> Any comments are appreciated.
>
> --
> Matthew H. North
> Technical Support Supervisor
> ___ ____ ___
> / / /__ Network | Tel 619/637-3600 | Mail: [EMAIL PROTECTED]
> /__ / ___/ Services | Fax 619/637-3630 | WWW: http://www.cts.com
> -- end of forwarded message --
>
> Ralf S. Engelschall
> [EMAIL PROTECTED]
> www.engelschall.com
> ______________________________________________________________________
> Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
> Official Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]